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ABSTRACT 


This  thesis  describes  the  potential  use  of  a  general-purpose  controller  autonomously 
to  measure  acoustic  vibration  in  the  Space  Shuttle  Cargo  Bay  during  launch.  The  ex¬ 
perimental  package  will  be  housed  in  a  Shuttle  Get  Away  Special  (GAS)  canister. 

We  have  implemented  the  control  functions  with  software  written  largely  in  the  C 
programming  language.  We  use  an  IBM  MS  DOS  computer  and  C  cross-compiler  to 
generate  Z-80  assembly  language  code,  assemble  and  link  this  code,  and  then  transfer  it 
to  EPROM  for  use  in  the  experiment's  controller.  The  software  is  written  in  a  modular 
fashion  to  permit  adapting  it  easily  to  other  applications.  The  software  combines  the 
experimental  control  functions  with  a  menu-driven,  diagnostic  subsystem  to  ensure  that 
the  software  will  operate  in  practice  as  it  does  in  theory  and  under  test. 

The  experiment  uses  many  peripheral  devices  controlled  by  the  software  described 
in  this  thesis.  These  devices  include:  a  solid-state  data  recorder,  a  bubble  memorx’ 
storage  module,  a  real-time  clock,  an  RS-232C  serial  interface,  a  power  control  subsys¬ 
tem,  a  matched  filter  subsystem  to  detect  activation  of  the  Space  Shuttle’s  auxiliary 
power  units  five  minutes  prior  to  launch,  a  launch  detection  subsystem  based  on 
vibrational  and  barometric  sensors,  analog-to-digital  converters,  and  a  heater  subsystem. 
The  matched  filter  design  is  discussed  in  detail  in  this  thesis,  and  the  results  of  a  com¬ 
puter  simulation  of  the  performance  of  its  most  critical  sub-circuit  are  presented. 
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Analog-to-digital  (A/D)  Converter:  Analog  signals  are  signals  whose  levels  var\'  con¬ 
tinuously  as  a  function  of  time.  Digital  signals  are  signals  which  take  on  discrete 
(quantized)  values,  and  these  values  remain  constant  for  some  given  period  of  time, 
at  which  time  the  level  is  updated.  An  analog-to-digital  converter  samples  a  contin¬ 
uous  input  signal,  decides  which  of  a  finite  set  of  discrete  values  is  the  best  one  to  de¬ 
scribe  the  input  signal,  and  outputs  that  discrete  value.  A  regular  clock  is  used  to 
cause  the  input  to  be  sampled  again  on  a  repetitive  basis,  and  the  output  likewise  is 
updated  at  the  same  rate.  A  digital  computer  cannot  deal  with  continuous  signal  lev¬ 
els,  so  A  D  converters  are  routinely  used  to  let  such  computers  read  signal  levels  in  the 
form  they  can  handle,  as  digital  values. 

Auxiliarv'  Pouer  Unit  (APLO:  The  APUs  are  jet-turbine-powered  engines  used  during 
both  launch  and  recoven.'  to  operate  the  control  surfaces  of  the  space  shuttle.  Because 
they  have  a  limited  amount  of  fuel,  the  mission  will  be  scrubbed  if  they  operate  for 
more  than  seven  minutes  before  launch.  The  Vibro-acoustic  Experiment  attempts  to 
detect  them.  If  it  is  successful  in  doing  so,  it  can  anticipate  launch. 

ASCII:  .American  Standard  Code  for  Information  Interchange.  Ihis  is  a  seven-bit 
data  code  used  in  many  digital  systems  to  represent  alphabetic  and  numeric  characters, 
punctuation  marks  and  a  number  of  non-printing  characters  conunonly  used  to  pass 
information  from  one  device  to  another.  Since  most  digital  systems  are  based  on 
eight-bit  bytes,  one  bit,  the  high-order  one.  is  unused  in  the  ASCII  scheme.  It  is  not 
uncommon  for  manufacturers  to  appropriate  the  extra  bit  for  their  own  purposes. 

BAUD:  The  baud  rate  is  the  number  of  symbols  transmitted  in  one  second.  In  many 
computer  systems,  one  symbol  can  represent  one  bit  (zero  or  one)  and  so  the  baud  rate 
and  the  bit  rate  are  equal. 

BCD:  Binary  Coded  Decimal.  In  this  format,  two  four-bit  codes  are  stored  in  a  single 
eight-bit  byte.  Each  of  these  four-bit  codes  can  take  on  any  of  ten  values  from  0x0 
through  0x9.  Values  from  Oxa  through  O.xf  are  forbidden.  The  interpretation  of  these 
four-bit  codes  is  that  they  represent  the  decimal  digits  from  0  through  9.  Thus,  a  single 
eight-bit  byte  can  represent  decimal  numbers  from  0  through  99.  This  format  is  the 
only  one  used  by  the  National  Semiconductor  .M.\I58167.A  real  time  clock. 

Bubble  Memorv':  This  is  a  form  of  integrated  circuit  memory  which  uses  magnetic 
domains  for  storing  information.  These  domains  look  like  bubbles  when  viewed  under 
a  microscope,  hence  the  name.  Applying  magnetic  fields  to  the  bubbles  causes  them 
to  mo\e  about,  permitting  the  information  they  represent  to  be  stored  and  retrieved. 
From  the  standpoint  of  a  user,  they  generally  have  two  chief  characteristics; 

1.  The  data  are  stored  in  a  combination  of  random  and  sequential  methods.  Thus 
groups  of  data  can  be  accessed  randomly,  but  the  elements  of  the  group  must  be 
accessed  sequentially.  This  is  analogous  to  the  way  a  disk  storage  device  oper¬ 
ates.  It  accesses  tracks  directly,  by  moving  its  read-write  head  radially  over  the 
disk's  surface  to  one  of  a  set  of  concentric  circles,  called  tracks.  Once  the  head 
is  positioned  over  the  desired  track,  data  is  sequentially  read  from  or  written  to 
it. 
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2.  The  data  they  contain  are  non-volatile.  Removing  power  from  them  does  not 
destroy  their  contents,  provided  this  is  done  in  a  controlled  manner.  This  is  in 
contrast  to  the  destruction  of  data  in  typical  integrated  circuit  memories  when 
power  is  removed  from  them.  Those  memories  are  non-volatile  only  if  a  battery 
backup  is  available.  The  Intel  bubble  memory  we  are  using  will  lose  data  if  the 
temperature  wanders  outside  the  range  (  —  20,  -i-  75rC  [Ref.  1:  Chapter  1,  p.3). 

Digital-to-analog  (D/A)  converters:  See  the  earlier  discussion  of  analog-io-digiial  con¬ 
verters  for  some  background  on  the  difference  between  analog  and  digital  signals.  The 
purpose  of  the  digital-to-analog  converter  is  to  convert  a  digital  signal  to  a  smoothly 
varying  continuous  signal.  Since  the  digital  signal  actually  varies  in  jumps,  it  is  not 
smooth  to  begin  with.  D  A  converters  use  low-pass  filters  to  eliminate  the  high- 
frequency  components  represented  by  the  sudden  jumps  of  a  digital  signal. 

Dynamic:  In  the  C  programming  language,  most  variables  are  dynamic.  This  means 
that  they  are  created  when  a  C  function  commences  executing  and  are  destroyed  when 
that  function  completes  e.xecuting.  This  is  in  contrast  to  the  way  static  (q.v.)  variables 
work. 

EE  PROM:  Electrically  erasable,  programmable  ROM  (q.v.).  The  contents  of 
EEPROMs  are  not  as  easily  modified  as  are  the  contents  of  R.\Ms.  but  they  are 
non-volatile  (they  don't  lose  their  contents  when  power  is  removed.)  The  contents  of 
these  memories  can  be  erased  electrically,  but  generally  at  a  much  slower  rate  than 
that  at  which  they  can  be  read. 

EPRO.M;  Erasable,  programmable  ROM  (q.v.).  EPRO.Ms  can  be  erased  for  re-use 
if  they  are  exposed  to  ultraviolet  light  for  several  minutes.  It  is  usual  to  remove  the 
integrated  circuit  from  the  circuit  board  to  do  this.  EPRO.Ms  have  a  limited  lifetime 
due  to  wear  on  the  pins  (unless  zero-insertion-force  sockets  are  used)  and  because  their 
ability  to  be  erased  diminishes  with  age. 

E.xecutable  Program  Module:  The  output  of  the  link  process  (q.v.)  is  a  single  file  of 
machine  code  instructions.  When  placed  in  the  computer's  memoiy  at  the  correct  lo¬ 
cations  (specified  in  advance),  these  instructions  permit  the  computer  to  execute  a 
program. 

FIFO:  First-in,  first-out.  This  term  refers  to  a  common  data  structure.  One  place 
this  data  structure  is  used  is  in  the  bulTer  on  the  bubble  memory  controller.  That 
bulTer  serves  as  an  intermediate  storage  area  between  the  bubble  memory  and  the  user. 
For  example,  when  data  are  being  read  from  the  bubble  memory  by  the  user,  they  are 
retrieved  from  the  bubble  memory  by  the  bubble  memory  controller  and  placed  in  the 
FIFO  bulfer.  Concurrently,  data  are  being  removed  from  the  bulTer  and  sent  to  the 
user.  The  first  characters  of  information  to  arrive  in  the  buffer  are  the  first  to  leave, 
hence  the  first  in  are  the  first  out. 

Firmware:  This  term  describes  the  computer  programs  which  are  stored  in  non¬ 
volatile  memory,  such  as  ROM  (^.v.) 

Handshaking:  When  two  devices  communicate,  they  employ  a  protocol  which  speci¬ 
fies  which  device  does  what,  when.  This  protocol  is  referred  to  as  "handshaking". 

He.xadecimal:  Numbers  to  the  base  16.  It  is  customary  to  use  the  usual  digits  (0-9) 
as  well  as  the  letters  ‘A’  (or  'a')  through  ‘F’  (or  T),  for  the  16  distinct  symbols  required 
in  this  system.  The  C  programming  language  by  convention  uses  the  prefix  ’OX'  (or 
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‘Ox’)  to  make  it  clear  that  the  appended  characters  represent  a  hexadecimal  quantity. 
For  example. 

2a, 6  =  0.r2a  s  2,6  x  16’  +  a,6  x  16°  s  2  x  16'  +  10  x  16°  =  42. 

Input/Output  space:  The  Z-80  and  the  essentially  similar  NSC800  provide  a  separate 
set  of  addresses  for  input  and  output  devices.  Certain  instructions  are  reserved  for 
these  addresses,  which  can  run  from  0x00  through  Oxff.  They  do  not  interfere  with  the 
corresponding  memory  address  space  (q.v.) 

I/O:  Input  or  output. 

I/O  Space:  See  Input/Output  Space. 

Latch  up:  A  comparator  will  ordinarily  produce  a  high  voltage  when  the  non¬ 
inverting  input  receives  a  higher  voltage  than  that  present  on  the  inverting  input. 
Similarly,  it  will  ordinarily  produce  a  low  voltage  when  the  iion-inverting  input  re¬ 
ceives  a  lower  voltage  than  that  present  on  the  inverting  input.  Some  comparators 
are  susceptible  to  the  phenomenon  called  “latch  up".  This  entails  a  failure  of  the 
comparator  to  change  its  output  according  to  the  usual  rules.  Instead,  the  output 
signal  will  remain  stuck  at  one  value  without  regard  to  changes  at  the  input.  This 
feature  is  highly  undesirable,  as  it  means  that  the  comparator  is  no  longer  performing 
as  it  should. 

Library:  The  output  of  the  compilation  or  assembly  steps  is  an  object  module.  Se¬ 
veral  of  these  can  be  stored  in  a  library  for  convenience.  During  the  link  process,  the 
linker  can  look  in  the  modules  stored  in  the  library  for  definitions  of  objects  whose 
names  it  does  not  recognize.  The  alternative  to  putting  modules  in  a  library  is  to 
specify  them  individually  to  the  linker,  which  is  somewhat  less  convenient. 

Linker:  The  linker  is  responsible  for  combining  the  object  modules  which  comprise 
a  complete  program,  and  placing  them  in  suitable  memory  locations.  Object  modules 
may  include  references  to  other  modules  or  identifiers  defined  within  other  modules. 
These  references  must  ultimately  be  resolved  to  memory  addresses  within  the  com¬ 
puter  which  will  run  the  executable  program.  It  is  the  job  of  the  linker  to  perform  this 
address  resolution.  To  link  a  program  is  to  request  the  linker  to  construct  an  execut¬ 
able  program,  and  res..lve  all  unknown  addresses.  The  object  modules  may  be  ob¬ 
tained  by  the  linker  from  either  of  two  sources:  from  a  library  or  from  individual  files 
containing  only  one  module  each.  The  output  from  the  linker  is  a  single  file  contain¬ 
ing  an  executable  program  module  {q.v.) 

Memory  address  space:  The  Z-80  and  the  essentially  similar  NSC800  permit  address¬ 
ing  memory  wich  addresses  in  the  range  0x0000  through  OxffiT.  Most  instructions 
which  use  addresses,  including  stack  instructions  which  do  not  explicitly  address 
memory,  use  this  space.  There  is  another  space  of  addresses  called  the  input  output 
space  {q.v.) 

Module:  In  the  C  programming  language,  many  functions  may  be  grouped  together 
in  a  single  file  of  source  code.  These  are  considered  to  comprise  a  single  module,  for 
they  are  compiled  as  a  unit  and  the  resultant  object  code  is  stored  in  a  single  file,  an 
object  module  ^q.v.}.  Similar  remarks  hold  when  the  source  code  consists  of  assembly 
language  instructions,  rather  than  instructions  in  the  C  programming  language.  In¬ 
deed,  this  concept  is  applicable  irrespective  of  the  programming  language  used  to  cre¬ 
ate  the  executable  program.  There  are  several  advantages  to  building  modules  in  this 
fashion.  Chief  among  them  is  the  separation  of  sections  of  a  program  according  to 
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their  functional  characteristics.  This  permits  testing  one  module  independent  of  test¬ 
ing  any  other  module.  It  also  facilitates  the  use  of  fully  debugged  programs  for  other 
applications  at  a  later  date. 

Modulo:  Consider  a  number  jc  and  another  number  m,  called  a  modulus.  The  number 
X  taken  modulo  m  is  written  x  mod  m  and  it  is  defined  to  be  the  least  positive  number 
n  such  that  x  =  k  "x  nt  +  n  for  some  integer  k.  As  an  e.xample,  5  mod  6  =  5  because 
0  X  6  5  =  5.  Similarly,  9  mod  6  =  3  because  9  =  I  x  6  -H  3,  and  —2  mod  6  =  4  since 

-2  =  —  1  X  6  -I-  4.  Although  we  can  also  write  -2  =  — 2  x  6  +  10,  -2  mod  6  10  be¬ 

cause  10  is  not  the  least  positive  number  which  can  be  found  to  satisfy  the  equation. 

Nibble:  A  nibble  is  a  half  byte.  This  is  a  typical  example  of  humor  in  the  computer 
business. 

NSC810A:  An  integrated  circuit  from  National  Semiconductor  which  includes  two 
eight-bit  ports,  one  si.x-bit  port,  128  eight-bit  words  of  R.AM  (q.v.)  and  two  16-bit  bi¬ 
nary  timers. 

Object  Module:  An  almost-executable  computer  program.  The  reason  it  is  not  fully 
executable  is  that  not  all  addresses  within  it  have  been  resolved  yet.  nor  has  the  linker 
established  what  addresses  should  be  assigned  to  relocatable  programs.  Assemblers 
and  compilers  produce  object  modules.  Linkers  convert  them  into  executable  form 
by  resolving  the  unresolved  addresses  and  assigning  all  relocatable  code  to  its  final 
location. 

Parametric  Registers:  The  Intel  BPK  5V75.-\  Four-Megabit  Bubble  Memory  includes 
five  parametric  registers  which  must  be  loaded  prior  to  attempting  to  perform  input 
from  or  output  to  the  bubble  memoty.  Two  of  the  five  comprise  the  block  length 
register,  which  defines  both  the  number  of  bytes  contained  in  a  page  of  bubble  mem- 
or>‘  {e.g.,  64),  and  the  number  of  pages  to  be  transferred  from  bubble  memor>  to  the 
bubble  memory  port  or  vice  versa  at  a  time.  Two  more  specify  at  which  of  the  8.192 
pages  in  the  bubble  memory  to  start  the  transfer  of  data.  The  last,  the  “enable”  reg¬ 
ister.  primarily  defines  whether  operation  is  to  be  interrupt-driven  or  not. 

Project  G-313:  This  is  the  designation  of  the  NASA  project  comprising  the  Vibro- 
acoustic  Experiment. 

PROM:  Programmable  ROM  iq.v.)  These  ROMs  can  be  written  to  once  by  the  user, 
but  once  written,  their  contents  can  never  be  modified. 

Quotation  Marks:  In  C,  double  quotation  marks  ("  ")  are  used  to  enclose  character 
strings.  Internally,  the  C  compiler  always  places  an  ASCII  NUL  character  (its 
hexadecimal  representation  is  0x00)  at  the  end  of  a  string.  Single  quotation  marks 
('  ')  are  used  to  enclose  a  single  character.  Internally,  the  C  compiler  does  not  append 
an  .ASCII  0x00  to  a  single  character. 

RAM:  Random  access  memory.  This  refers  primarily  to  memory  which  can  be  writ¬ 
ten  to  and  read  from  repeatedly.  It  commonly  is  volatile,  i.e.,  its  contents  are  de¬ 
stroyed  when  power  is  removed. 

ROM:  Read-only  memory.  This  term  is  a  bit  of  a  misnomer.  Obviously  a  memory 
which  can  never  be  written  to  would  be  of  little  value.  Generally,  it  is  much  more 
difficult  to  modify  the  contents  of  a  ROM  than  it  is  to  modify  the  contents  of  a  RAM. 
ROMs  come  in  several  varieties: 
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1.  A  mask-programmed  ROM  receives  its  data  at  the  factory  according  to  a 
customer's  specification  when  it  is  manufactured. 

2.  A  PROM  iq.v.)  is  programmed  once  by  the  user. 

3.  An  EPROM  (q.v.)  can  be  programmed  repeatedly,  but  must  be  erased  by  ultra¬ 
violet  light  between  uses. 

4.  An  EEPROM  (^.v.)  also  can  be  programmed  repeatedly,  but  it  can  be  erased 
electrically. 

RS-232C  Serial  Interface:  This  interface  is  also  known  as  the  EIA  standard  interface 
It  was  developed  in  1969  by  the  Electronic  Industries  Association  in  conjunction  with 
the  Bell  system,  as  well  as  independent  manufacturers  of  computers  and  modems. 
Data  are  transmitted  serially  using  two  voltage  levels.  -I-  V,  represents  a  binar>^  0; 
—  V,  represents  a  binarv'  1. 

The  voltage  V,  can  lie  within  the  range  (3,25jV.  While  the  RS-232C  defines  the 
electrical  characteristics  of  the  interface,  the  functional  description  of  the  interchange 
circuits,  and  lists  standard  applications,  it  is  silent  on  the  subject  of  physical  connec¬ 
tors.  Usuallv.  however,  DB-25  connectors  havine  25  pins  are  used.  The  tables  in 
APPENDIX  !.  RS-232C  INTERFACE  PIN  CONNECTIONS  on  page  224  show 

the  pin  connections  for  the  RS-232C  interface.  (Ref  2:  p.  683] 

SSDR:  Solid  State  Data  Recorder.  This  device  stores  audio  data  in  magnetic  bubble 
memories.  It  accepts  conmiands  analogous  to  those  selected  by  pushing  a  button  on 
a  con\entionaI.  reel-to-reel  tape  recorder.  For  e.xample.  the  commands  PLAY'  and 
RECORD  exist.  However,  access  to  the  data  can  be  random. 

Static:  In  C.  most  variables  are  dynamic  (qs.)  They  can  be  made  static  by  the  inclu¬ 
sion  of  this  keword  in  their  declarations.  This  causes  them  to  become  permanent. 
They  are  not  then  created  when  the  function  in  which  they  are  declared  starts  to  exe¬ 
cute.  They  are  created  at  the  time  of  compilation.  They  do  not  lose  their  contents 
when  that  function’s  operation  ends.  The  contents  of  the  storage  locations  assigned 
to  them  remain  intact  until  the  next  time  that  function  tries  to  access  that  variabre. 

UART  (Universal  Asynchronous  Receiver-Transmitter):  A  common  integrated  circuit 
which  provides  asynchronous  communications  between  two  hardware  devices.  We  use 
it  to  implement  an  PxS-232C  serial  interface  between  the  controller  hardware  and  a 
terminal. 

Volatile  Memory  Storage:  Conventional  RA.M  (^.v.)  loses  its  contents  when  power  is 
removed.  This  property  is  called  volatility.  By  contrast,  magnetic  core  and  bubble 
memories  are  non-volatile.  For  that  matter,  printed  pages  are  also  non-volatile 
memories. 

Voltage  Controlled  Oscillator  (VCO):  The  VCO  operates  a  loudspeaker  in  the  exper¬ 
iment  during  the  sweep  phase.  The  frequencies  are  increased  incrementally  between 
35  Hz  and  785  Hz  in  1  Hz  increments. 
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I.  INTRODUCTION 


Since  it  began  flying  into  space  in  April,  1981  the  Space  Shuttle  has  made  it  much 
easier  to  get  payloads  into  space.  Although  the  shuttle  was  grounded  because  of  the 
tragic  explosion  of  the  Challenger  on  January  28,  1986,  flights  resumed  in  October,  1988. 

A.  GET  AWAY  SPECIAL  (GAS) 

In  1976  the  National  Aeronautics  and  Space  Administration  (NASA)  established  the 
Get  Away  Special  (GAS)  program  (Ref.  3:  p.ll).  The  purpose  of  this  program  is  to 
permit  individual  experimenters  to  have  room  on  the  Space  Shuttle  for  their  experiments, 
provided  there  is  no  undue  interference  with  the  rest  of  the  mission  as  a  result.  To  pre¬ 
clude  such  interference.  N.AS.A  therefore  imposes  a  number  of  constraints  on  these  ex¬ 
periments.  Among  these  are 

1.  They  must  contain  their  own  power  source,  heating,  data  handling  facilities,  and 
so  on  [Ref  4:  p.S]. 

2.  No  more  than  three  external  switches  may  be  provided  for  operation  by  crew¬ 
members.  Of  these,  one  must  be  devoted  to  removing  all  power  from  the  pavload 
[Ref  4:  p.  28]. 

The  Space  Shuttle  is  subject  to  powerful  acoustic  vibrations  during  launch.  In  the 
past,  minor  breakage  of  crystals  and  circuit  boards  has  resulted  [Ref  3:  p.llj.  It  is 
thought  that  the  vibrations  are  responsible  for  this  damage,  and  that  some  regions  of  the 
cargo  bay  are  more  susceptible  to  damage  than  others.  Acoustical  analysis  of  the  sound 
waves  which  cause  these  vibrations  could  reveal  where  the  best  and  worst  locations  are. 

Several  early  GAS  experiments  carried  conventional  reel-to-reel  tape  recorders  and 
were  intended  to  record  the  acoustic  waves  in  the  cargo  bay  for  subsequent  analysis. 
However,  the  analysis  was  flawed  for  several  reasons  [Ref  5:  p.  15).  Among  these  were: 

1.  The  microphones  were  mounted  close  to  the  bulkhead  of  the  cargo  bay,  within  a 
partial  enclosure.  Thus  the  data  might  have  been  erroneous. 

2.  The  data  recorded  by  the  microphone  may  have  been  contaminated  by  interaction 
between  the  microphone  and  its  isolation  system. 

3.  The  acoustical  waves  in  the  forward  third  of  the  cargo  bay  were  not  recorded. 

Furthermore,  astronauts  were  too  busy  at  launch  time  personally  to  initiate  the  exper¬ 
iments  Instead,  the  experiments  included  circuitry  to  detect  the  roar  of  the  main  engines 
and  trigger  the  commencement  of  the  e.xperiment  [Ref  6:  p.  1  Ij.  There  is  good  reason 


to  doubt  the  validity  of  the  analysis  of  acoustic  waves  whose  collection  was  itself  trig¬ 
gered  by  the  occurrence  of  those  same  waves.  As  a  result  of  all  these  factors,  the  anal¬ 
ysis  so  far  has  been  ambiguous. 

B.  THE  VIBRO-ACOUSTIC  EXPERIMENT 

The  Space  Systems  Academic  Group  at  the  Naval  Postgraduate  School  plans  to 
conduct  an  experiment  as  N.ASA  project  G-313  to  obtain  improved  acoustical  meas¬ 
urements  in  the  cargo  bay  of  the  Space  Shuttle  during  launch.  In  the  remainder  of  this 
thesis,  we  shall  refer  to  this  project  as  the  Vibro-acoustic  Experiment.  The  reader  is  re¬ 
ferred  to  [Ref.  7]  for  a  general  overview  of  the  experiment. 

The  purpose  of  this  thesis  is  to  describe  the  software  and  some  of  the  hardware 
which  controls  the  Vibro-acoustic  Experiment.  At  times  this  thesis  will  merely  describe 
the  work  we  have  done.  At  other  times,  it  will  prescribe  what  to  do  to  achieve  various 
ends.  Thus  it  will  serve  not  merely  as  documentation  of  what  has  been  done,  but  it  will 
also  serve  as  a  manual  for  those  who  might  wish  to  elaborate  on  this  earlier  work. 

The  majority  of  the  work  performed  by  the  author  had  to  do  merely  with  the  control 
of  the  experiment.  However,  the  matched  filter  (described  in  Chapter  HI.  THE 
-M.ATCHED  FILTER  on  page  21)  was  redesigned  by  the  author  and  is  completely  de¬ 
scribed  in  this  thesis. 

A  great  deal  of  the  hardware  and  software  created  to  control  the  Vibro-acoustic 
experiment  is  ver>'  general  in  nature,  and  would  apply  without  change  to  other  exper¬ 
iments.  We  will  attempt  to  indicate  which  components  have  general  applicability.  The 
hope  is  that  future  applications  will  benefit  from  this  approach,  and  will  be  spared  the 
need  to  build  and  program  a  controller  from  scratch.  .More  information  on  the 
general-purpose  controller  hardware  we  use  in  the  Vibro-acoustic  Experiment  can  be 
found  in  Chapter  II.  CONTROL  HARDWARE  on  page  10.  The  software  is  described 
in  general  terms  in  Chapter  IV.  DESIGN  OF  THE  CONTROL  SOFTWARE  on  page 
43. 

C.  DIFFERENCES  FROM  EARLIER  EFFORTS 

Like  earlier  experiments,  this  one  is  housed  in  a  GAS  canister.  It  differs  from  them, 
however,  in  several  key  respects. 

1.  Isolation  of  Microphones 

The  experiment  uses  microphones  housed  in  a  mounting  designed  at  the  Naval 
Postgraduate  School  to  isolate  them  from  vibration.  This  is  intended  to  reduce  the 
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contamination  of  the  recorded  acoustical  waves  by  structural  vibrations.  This  micro¬ 
phone  arrangement  is  described  in  Stchle  [Ref.  5]. 

2.  Solid  State  Data  Recorder  (SSDR)  Using  Bubble  Memory 

Conventional  reel-to-reel  tape  recorders  are  supplanted  by  a  recorder  using 
magnetic  bubble  storage.  This  recorder  was  also  designed  at  the  Naval  Postgraduate 
School  and  has  the  following  advantages  over  conventional  recorders. 

1.  It  contains  no  moving  parts,  so  is  less  prone  to  mechanical  failure. 

2.  It  permits  random  access  to  data,  not  possible  with  tape.  While  such  a  capability 
is  commonplace  with  disk  storage,  disks  do  suffer  from  mechanical  breakdown. 
Also,  they  are  vulnerable  to  errors  when  external  accelerations  occur,  as  they  do 
during  a  launch.  This  is  less  problematic  in  the  case  of  bubble  memories. 

3.  Bubble  memory  is  non-volatile,  that  is,  its  contents  are  not  destroyed  when  power 
is  removed.  Thus  battery  power  is  not  required  to  keep  tlie  stored  data  a%ailable. 
Slightly  offsetting  this  advantage  is  the  fact  that  power  must  be  removed  in  a  con¬ 
trolled  fashion,  and  specified  temperature  limits  must  be  maintained. 

The  magnetic  bubble  recorder  is  described  in  Frey  (Ref.  8]. 

3.  Microprocessor  Control  of  the  Experiment 

To  operate  the  experiment,  another  group  at  the  Naval  Postgraduate  School 
built  a  single-board,  microprocessor-based  controller.  This  general-purpose  controller 
uses  a  National  Semiconductor  NSC800  microprocessor  (roughly  equivalent  in  function 
to  a  Zilog  Z-80).  This  controller,  as  it  was  originally  conceived,  is  described  in  Wallin 
(Ref  3j.  From  a  programmer's  standpoint,  the  controller  has  the  characteristics  de¬ 
scribed  in  Chapter  II.  Section  A.  Standard  Controller  on  page  10. 

The  controller  will  be  responsible  for: 

1.  activating  all  subsystems  at  the  appropriate  time; 

2.  monitoring  execution  of  the  experiment; 

3.  keeping  a  log  of  significant  events  and  the  dates  and  times  at  which  they  occurred. 
This  log  is  stored  in  the  controller’s  bubble  memory  module; 

4.  recording  temperature  and  voltage  readings  while  the  shuttle  is  in  space;  and 

5.  ensuring  that  the  bubble  memories  do  not  get  too  cold.  This  is  done  by 
intermittently  operating  the  heater  subsystem  to  maintain  a  temperature  above 
10°C  .  [Ref.  1:  p.  3] 

In  addition  to  the  obvious  functions  called  for  in  controlling  the  experiment,  the  soft¬ 
ware  also  contains  a  menu-driven  diagnostic  subsystem  to  provide  for  testing  on  the 
ground.  (See  APPENDIX  B.  CHOICE  OF  A  SOFTWARE  DEVELOPMENT  SYS- 
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TEM  on  page  83  for  a  general  description  of  the  several  software  development  systems 
we  have  used.) 

D.  PROCEDURAL  OUTLINE  OF  THE  VIBRO-ACOUSTIC  EXPERIMENT 

In  this  section  we  sketch  an  outline  of  the  operation  of  the  Vibro-acoustic  Exper¬ 
iment.  The  flowcharts  in  Chapter  IV,  Section  2.  Performing  the  Experiment  on  page 
46  show  the  procedure  which  the  experiment  follows.  A  synopsis  of  this  procedure  is 
provided  here.i  The  experiment  begins  to  operate  when  the  ground  crew  or  astronauts 
turn  on  a  switch  in  the  cabin,  causing  power  to  be  applied  to  the  GAS  canister  which 
houses  the  experiment.  With  power  applied,  the  microprocessor  comes  to  life.  Its  first 
task  is  to  initialize  the  programmable  hardware  ports  and  timers.  It  then  has  to  decide 
whether  or  not  to  perform  the  complete  e.xperiment  or  an  abridged  version  of  it.  The 
need  for  such  a  decision  will  become  apparent  presently.  For  the  moment  we  will  con¬ 
fine  our  attention  to  the  unabridged  experiment. 

1.  S>veep  Phase 

Once  the  cargo  bay  has  been  loaded,  the  ground  crew  will  activate  the  exper¬ 
iment  for  about  an  hour  to  let  it  perform  the  .  ,  phase.  During  this  phase,  the  cargo 
bay  is  irradiated  with  a  sequence  of  acoustic  tones  of  known  frequencies  and  the  acoustic 
response  of  the  enclosure  is  recorded  by  the  Solid  State  Digital  Recorder  (SSDR).  After 
the  mission,  analyzing  this  data  [Ref.  9]  and  comparing  it  to  the  echoes  recorded  during 
launch  will  reveal  the  locations  of  the  regions  most  and  least  prone  to  damage  from  vi¬ 
bration.  This  phase  is  the  longest,  and  lasts  13  minutes. 

2.  Detection  of  the  Au.xiliary  Power  Units  (APUs) 

The  Space  Shuttle’s  .Auxiliary  Power  Units  (.APUs)  are  jet  turbines  used  to  op¬ 
erate  control  surfaces  during  launch  and  recover}'  of  the  shuttle.  The  .APUs  start  to 
operate  around  five  minutes  before  launch.  Because  they  emit  a  characteristic  frequency 
at  600  Hz,  we  can  use  a  matched  filter  to  detect  their  acoustic  signature 
[Ref.  6:  pp.  15-18].  When  the  matched  filter  detects  this  signal,  it  knows  that  launch 
is  imminent,  and  it  is  time  to  start  recording  the  sounds  which  occur  prior  to  launch. 
Thus  we  w'ill  record  the  sounds  before,  during,  and  after  launch.  By  not  waiting  for  the 
roar  of  the  main  rocket  engines  before  starting  to  record  the  ambient  noise,  we  will  avoid 
the  problem  mentioned  in  Chapter  1,  Section  A.  Get  Away  Special  (GAS)  on  page  1. 
The  data  collected  by  this  means  should  be  much  more  accurate. 

1  See  Chapter  IV,  Section  B.  Operation  of  the  Vibro-acoustic  Experiment  on  page  45  for 
complete  details. 
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Since  there  exists  the  possibility  that  for  some  reason  the  matched  filter  will  fail 
to  detect  the  APUs,  the  experiment  includes  two  backup  systems. 

1 .  The  V' ibration-activated  Launch  Detector  will  detect  the  vibrations  associated  with 
launch. 

2.  A  second  backup  system  will  use  two  barometric  pressure  switches  to  detect  the 
drop  in  atmospheric  pressure  which  occurs  as  the  Space  Shuttle  rises.  These 
switches  will  be  placed  in  a  redundant,  parallel  configuration.  Thus,  if  either  one 
or  both  of  them  work,  the  drop  in  barometric  pressure  will  be  detected. 

Neither  of  these  systems  can  detect  operation  of  the  APUs.  However,  if  either  one 
should  detect  a  launch,  the  control  program  stops  waiting  for  the  APUs  to  come  on  and 
switches  immediately  to  the  launch  phase. 

If  the  matched  filter  successfully  detects  the  APUs  but  the  Vibration-activated 
Launch  Detector  fails  to  detect  launch,  the  barometric  sensor  will  cause  the  experiment 
to  switch  to  launch  phase,  albeit  a  little  late. 

It  would  be  unfortunate  if  the  matched  filter  failed  to  detect  the  .APUs,  for  then 
one  of  the  primaiy  advantages  of  the  Vibro-acoustic  Experiment  over  earlier  efforts  to 
record  acoustical  noise  in  the  Space  Shuttle  would  disappear.  It  would  be  doubly  un¬ 
fortunate  if  neither  the  matched  filter  nor  the  vibration  detection  subsystem  worked,  for 
then  no  data  would  be  recorded  until  well  after  launch.  If  any  one  of  the  three  systems 
works  as  designed,  then  the  experiment  will  acquire  at  least  some  data. 

3.  Scroll  Phase 

If  the  matched  filter  detects  the  .APUs,  the  control  program  will  place  the  Solid 
State  Data  Recorder  (SSDR)  into  scroll  mode.  In  this  mode,  the  SSDR  uses  a  subset 
of  its  bubble  memory  for  recording  the  ambient  noise  prior  to  launch.  The  fraction  of 
memory  dedicated  to  this  purpose  permits  at  most  1 10  seconds  of  recording  time.  Once 
this  memory  is  used  up,  the  SSDR  will  start  re-using  it  from  the  beginning.-  .\s  a  result 
of  this  mode  of  operation,  roughly  two  minutes  of  pre-launch  noise  will  be  recorded, 
along  with  the  noise  of  the  ignition  of  the  main  engines. 

4.  Launch  Phase 

Either  the  vibration  detection  subsystem  or  the  barometric  sensors  can  trigger 
detection  of  a  launch.  When  a  launch  is  detected,  the  control  program  puts  the  SSDR 
mto  launch  mode.  The  purpose  of  this  mode  is  to  record  the  noise  after  the  launch  be¬ 
gins.  In  launch  mode,  enough  memory  is  dedicated  to  permit  about  two  minutes  of 

2  In  effect,  the  SSDR  is  writing  onto  a  continuous,  looped  scroll,  hence  the  name  of  this  mode 
of  operation. 
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ambient  noise  to  be  recorded.3  Once  this  memory  is  exhausted,  the  SSDR  will  signal  the 
control  program  that  it  has  finished  operations. 

5.  Post-launch  Operations 

After  the  SSDR  has  signalled  completion,  the  Vibro-acoustic  Experiment  has 
finished  gathering  all  the  acoustical  data  it  needs.  The  controller  will  continue,  however, 
to  monitor  and  record  temperature  in  the  GAS  canister  and  record  this  information  in 
its  own  bubble  memory  module.  It  will  also  monitor  and  record  voltage  levels  of  each 
of  three  power  supply  batteries.  If  these  should  fall  below  8.5V,  it  will  halt.  This  pre¬ 
vents  loss  of  data  in  the  bubble  memor>'  due  to  insufficient  voltage  and  current  levels. 

The  basis  for  choosing  8.5V  follows.  Each  individual  cell  is  rated  for  2.0V\ 
There  are  five  of  these  cells  in  the  10  V  stack  which  powers  the  bubble  memory'.  If  any 
cell  drops  to  1.81V  or  below,  it  is  considered  to  be  below  the  operating  threshold.  Five 
such  cells  generate  9.05  V.  The  bubble  memory  itself  can  operate  on  as  little  as  5  V. 
We  know  that  the  batteries  are  losing  power  when  the  voltage  falls  below  8.5  V,  but  we 
still  have  a  margin  of  3.5  V  above  the  voltage  required  to  operate  the  bubble  memory. 
(The  margin  is  reduced  slightly  due  to  the  presence  of  5  V  voltage  regulators  in  the  cir¬ 
cuit,  but  it  is  still  ample.)  It  is  therefore  reasonable  to  halt  operations  if  the  voltage  falls 
below  S.5V  . 

Also,  if  the  temperature  of  the  bubble  memory  falls  below  10®C.  it  is  below  the 
minimum  operating  temperature,  and  we  will  suspend  operation  of  the  bubble  memory 
until  the  temperature  returns  to  10°C  once  more.  Likewise,  if  the  temperature  should 
rise  above  55°C,  it  is  above  the  maximum  operating  temperature,  and  bubble  inemoiy 
operations  will  be  suspended  until  the  temperature  drops  within  the  operating  range 
again. [Ref  1:  Chapter  1.  p.  3] 

6.  Abridged  E.xperiment 

NASA  has  balked  at  the  idea  of  our  performing  the  sweep  phase.  They  are 
concerned  over  the  possibility  that  the  loud  sounds  generated  during  the  sweep  might 
damage  other  payloads  or  frighten  technicians.  They  also  are  reluctant  to  remove  per- 

3  Since  the  shuttle's  cargo  bay  is  not  pressurized,  the  air  will  leak  out  as  the  outside  pressure 
drops.  After  t%vo  minutes,  there  will  be  no  appreciable  atmosphere  left  inside  the  cargo  bay,  and 
all  sound  will  have  ceased. 

4  These  checks  are  only  performed  during  the  post-launch  phase,  which  begins  within  two  or 
three  minutes  from  the  time  of  launch.  It  is  unlikely  that  NASA  would  launch  the  shuttle  if  the 
outside  temperature  were  below  lO'C,  and  we  do  not  anticipate  that  the  temperature  will  fall 
appreciably  within  the  first  three  minutes  of  flight. 
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sonnel  from  the  vicinity  of  the  shuttle  during  that  phase.  They  are  equally  reluctant  to 
require  those  personnel  to  wear  hearing  protection  during  the  sweep. 

Those  arguments  seem  specious  to  us.  It  strikes  us  as  unlikely  that  damage  to 
equipment  might  result  from  the  sweep  but  not  from  the  rocket  motor  noise  during  lift 
off.  We  cannot  see  the  reason  why  personnel  whose  hearing  might  be  damaged  during 
the  sweep  cannot  wear  hearing  protection.  While  we  can  still  perform  an  analysis  of  the 
recorded  data  without  first  doing  a  sweep,  it  is  likely  to  produce  less  useful  results. 

We  have  decided  to  proceed  as  we  wanted  to  originally,  that  is,  to  design  an 
experiment  which  would  do  everything  we  want.  We  have  added  an  additional  decision 
point  to  permit  the  abridged  experiment  to  take  place.  This  shortened  experiment  would 
simply  turn  on  the  recorder  when  the  APUs  were  detected  or  when  launch  occurred,  and 
we  would  hope  for  the  best.  There  would  be  no  sweep,  no  scroll,  and  no  launch  phases; 
there  would  only  be  a  record  phase,  once  the  APL's  or  a  launch  were  detected. 

Once  NASA  sees  that  the  abridged  experiment  works,  that  the  analysis  provides 
good  results,  and  that  permitting  the  unabridged  experiment  will  yield  even  better  data, 
we  hope  that  they  will  relent  and  permit  us  to  fly  the  experiment  again  in  the  unabridged 
mode. 

E.  IRREGULARITIES 

What  happens  if  the  power  fails  temporarily  and  then  is  restored?  This  might  hap¬ 
pen  if  the  power  switch  is  inadvertently  switched  olT  by  the  ground  or  flight  crew,  or 
through  some  equipment  malfunction.  Upon  the  restoration  of  power,  the  micro¬ 
processor  must  decide  where  in  its  procedure  to  resume  execution.  There  are  several 
cases  to  consider. 

1.  The  sweep  phase  has  never  been  initiated,  nor  has  a  launch  occurred.  The  correct 
action  is  to  start  at  the  beginning. 

2.  The  sweep  phase  has  been  initiated.  It  is  not  known  whether  or  not  it  ever  was 
completed,  but  a  launch  has  not  occurred.  The  correct  action  is  to  skip  the  sweep 
phase  and  vvait  for  some  indication  of  a  launch.  The  sweep  creates  a  very  loud 
noise  which  would  be  hazardous  to  ground  personnel  if  it  were  permitted  to  occur 
at  other  than  a  scheduled  time.  Since  this  time  is  not  known  at  present,  and  never 
is  firmly  enough  known  in  advance  to  be  programmed  into  the  computer,  we  can¬ 
not  risk  running  the  sweep  phase  if  it  is  interrupted  by  a  power  fault. 

3.  The  sweep  phase  has  been  initiated  (and  presumably  completed),  the  APUs  are  on, 
but  no  indications  of  a  launch  are  present.  The  correct  action  is  to  enter  scroll 
mode.  If  it  was  already  in  progress  when  the  power  fault  occurred,  it  will  be  re¬ 
started.  This  is  all  right,  since  no  vital  information  will  be  lost  by  this  procedure. 

4.  The  sweep  phase  has  been  initiated  (and  presumably  completed)  and  conditions  of 
a  launch  are  present  but  the  barometric  switch  has  never  been  tripped.  The  correct 


action  is  to  assume  we  are  just  beginning  a  launch  and  to  initiate  launch  mode. 
This  creates  a  risk  that  recordings  of  the  moment  of  launch  would  be  lost  if  a  power 
fault  occurred  between  the  moment  of  launch  and  the  triggering  of  the  barometric 
switch  as  the  spacecraft  ascends.  There  is  no  obvious  way  entirely  to  eliminate  this 
risk. 

5.  The  sweep  phase  was  initiated  (and  presumably  completed)  and  the  barometric 
switches  were  activated  at  some  earlier  point.  This  implies  that  the  power  fault 
took  place  after  the  activation  of  the  barometric  switches,  that  is,  after  launch.  The 
correct  action  is  to  assume  that  launch  data  was  successfully  recorded  and  to  initi¬ 
ate  the  post-launch  monitoring  operations. 

F.  OTHER  APPLICATIONS 

The  controller  hardware  is  sufficiently  powerful  that  it  could  easily  provide  control 
for  other  applications.  In  particular,  many  spaceborne  applications  could  be  operated 
by  it. 

In  the  course  of  developing  the  control  software,  we  had  to  create  support  routines 
to  take  care  of  a  great  many  mundane  functions.  In  computers  with  operating  systems, 
these  functions  are  typically  provided  by  the  operating  system.  The  user  has  merely  to 
know  about  them  and  use  them. 

The  controller  we  use  has  no  operating  system,  so  we  had  to  create  many  low-level 
functions,  e.g.,  one  which  converts  a  hexadecimal  number  to  a  character  string  repres¬ 
enting  that  number. 

At  a  higher  level,  we  wrote  subroutines  to  display  text  on  a  terminal,  operate  a 
bubble  memory,  operate  a  real-time  clock,  and  control  various  e.xternal  devices  through 
the  44  input  and  output  lines  provided  with  the  controller. 

By  using  the  low-level  subroutines,  and  by  organizing  an  application’s  software  in 
a  similar  manner,  much  of  the  most  tedious  and  uninspiring  work  entailed  in  producing 
a  control  program  for  this  controller  hardware  could  be  avoided.  This  would  leave  more 
time  to  devote  to  the  real  purpose  of  the  application.  In  an  environment  with  few  people 
available  to  do  the  work,  such  economy  is  ver>’  attractive. 

Another  consideration  is  the  lack  of  a  need  to  use  assembly  language  in  program¬ 
ming  the  controller.  In  the  very  few  places  where  it  was  required,  we  used  it.  Along 
with  the  large  collection  of  C  language  subroutines  of  general  applicability,  the  routines 
we  have  already  provided  in  assembly  language  should  suffice  for  almost  all  run-of-the- 
mill  work. 

In  one  area  we  were  ourselves  compelled  to  abandon  the  use  of  C  language  source 
code  and  switch  to  assembly  language  code.  We  initially  hoped  that  only  the  start-up 
code,  the  input  routine,  the  output  routine  and  the  software  delay  routine  would  require 
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the  use  of  assembly  code.  We  assumed  we  could  input  from  and  output  to  the  bubble 
memory  using  compiled  C  language  source  code. 

This  assumption  turned  out  to  be  incorrect.  We  needed  a  data  transfer  rate  of 
16,000  bytes  per  second  [Ref  1:  Chapter  1,  p.  3],  but  could  only  attain  around  3,000 
bytes  per  second.  Consequently,  we  had  to  replace  a  small  section  of  C  code  with  as¬ 
sembly  language  source  code.  Even  this  was  necessary  only  because  we  used  a  prototype 
bubble  memory  board  with  a  buffer  whose  size  was  inadequate  to  handle  data  transfers. 
While  this  buffer  provided  only  40  characters  of  space,  we  needed  64. 

When  speed  becomes  paramount,  assembly  code  may  be  necessary,  since  it  can  be 
tailored  to  the  job  at  hand  and  so  produce  very  efficient  programs.?  For  many  applica¬ 
tions,  however,  speed  is  not  critical.  It  ordinarily  is  foolish  to  waste  time  achieving  in 
assembly  language  what  can  be  done  much  more  quickly  using  a  high-level  language. 
Only  if  you  cannot  achieve  the  desired  performance  with  a  high-level  language,  must  you 
use  assembly  language. 

Irrespective  of  whether  some  portion  of  an  application  does  or  does  not  demand 
eHlcient  code  (written  in  assembly  language),  for  most  applications  the  majority  of  the 
code  can  be  written  in  a  high-level  language  such  as  C.  Many  applications,  too.  need 
no  more  facilities  than  those  provided  in  the  Vibro-acousiic  Experiment.  In  such  cases, 
building  on  the  work  presented  in  this  thesis  has  very^  clear  advantages. 


5  Nonetheless,  some  optimizing  compilers  surpass  quite  competent  assembly  language  pro¬ 
grammers  in  efficiency. 
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n.  CONTROL  HARDWARE 

The  controller  we  use  in  the  Vibro-acoustic  Experiment  is  based  on  the  NSC800 
microprocessor.  For  all  practical  purposes,  this  is  functionally  equivalent  to  the  Zilog 
Z-806  [Ref.  10].  Figure  I  on  page  1 1  is  a  block  diagram  showing  the  major  components 
of  the  system.  To  the  left  of  the  microprocessor  appear  those  peripherals  which  ordi¬ 
narily  fall  under  the  control  of  the  standard  controller.  We  discuss  these  peripherals  and 
their  capabilities  in  Section  A.  Standard  Controller  below.  One  can  connect  an  assort¬ 
ment  of  devices  to  the  44  input  and  output  lines  available  on  it.  Other  applications  than 
the  Vibro-acoustic  experiment  could  use  this  bare-bones  controller  for  their  own  pur¬ 
poses. 

To  the  right  of  the  microprocessor  appear  those  peripherals  which  are  peculiar  to 
the  Vibro-acoustic  Experiment.  We  discuss  these  peripherals  and  their  capabilities  in 
Section  B.  Additional  Controller  Hardware  on  page  14  below. 

A.  STANDARD  CONTROLLER 
I,  NSC810A  RAM-I/O-Timers 

Two  NSC810.A  R.-\M-I  0-Timer  units  provide  four  eight-bit  ports  and  two  six- 
bit  ports.  These  provide  44  bits  of  input  and  output  capability.  There  also  are  two 
timers  on  each  device.  One  of  each  pair  is  completely  independent  of  the  data  ports:  the 
other,  if  used,  reduces  the  number  of  available  pins  in  the  six-bit  port  to  three.  We  have 
configured  the  system  such  that  one  of  the  latter  kind  of  timer  is  unavailable,  since  we 
have  dedicated  the  data  lines  with  which  it  interferes  to  other  purposes.  The  two  timers 
which  do  not  conflict  with  any  data  lines  at  all  are  dedicated  to  providing: 

1.  A  153.6  kHz  signal  to  the  IM6402  Universal  Asynchronous  Receiver  Transmitter 
(UART)  where  it  is  divided  by  16  to  yield  a  9600  BAUD  clock  for  serial  data 
transmission. 

2.  A  614.4  kHz  clock  which  is  provided  to  the  ADC0816  Analog-to-Digital  Converter. 

Thus  one  of  the  four  timers  is  available  for  other  uses. 

We  shall  hereafter  refer  to  the  tw’o  devices  as  NSC810A  #1  and  NSC810A  #2 
respectively.  The  NSC810A  reference  manual  [Ref.  11]  refers  to  the  eight-bit  ports  by 

6  The  NSC800  includes  several  instructions  not  included  with  the  Z-80.  Since  the  Z-80  is  the 
better-known  device,  we  have  not  used  any  of  the  added  instructions. 
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the  letters  A  and  B,  and  to  the  six-bit  port  by  the  letter  C.  In  the  rest  of  this  thesis,  when 
we  wish  to  distinguish  between  ports  on  NSCSIOA  #1  and  NSC810A  r?2.  we  shall  ap¬ 
pend  a  subscript  to  the  port's  letter,  e.g..  A,  is  NSCSIOA  #1,  port  A. 

NSCSIOA  #1  uses  port  addresses  0x00  through  0x19.7  NSCSIOA  #2  uses  port 
addresses  0x20  through  0x39.8 

General  information  on  programming  the  NSCSIOA  can  be  found  in  [Ref.  11]. 
We  present  the  specific  manner  in  which  these  devices  have  been  programmed  for  the 
Vibro-acoustic  Experiment  in  Section  A.  Major  Subroutines  and  Functions  on  page 
108. 

2.  On-board  Analog-to-digital  Converter 

An  eight-bit,  16-channel.  National  Semiconductor  ADC0S16  analog-to-digital 
{A  D)  converter  permits  the  monitoring  of  voltages  and  temperatures  at  various  points 
within  the  experiment.  It  can  be  mounted  right  on  the  microprocessor-based  controller 
board.  The  device  is  connected  starting  at  input  output  space  address  OxSO.  Conversion 
of  an  analog  input  to  a  digital  number  is  signalled  to  the  control  program  by  the  exist¬ 
ence  of  a  1  in  bit  3  of  port  C,. 

3.  Bubble  Memory  Module  for  the  Controller 

Devoted  to  the  use  of  the  controller  board  is  a  512  KByte  Intel  BPK  5V75.-\ 
Four-Megabit  Bubble  Memory  Prototype  Kit.  The  control  program  will  maintain  a  log 
in  this  memorx'  of  all  actions  it  takes  during  the  experiment.  The  information  will  in¬ 
clude  a  code  signifying  the  action  taken,  the  time  and  date  of  that  action,  and  the  current 
temperature  and  voltage  readings. 

.After  launch,  the  Vibro-acoustic  Experiment  is  over.  The  control  program  then 
uses  the  log  solely  for  the  purpose  of  recording  temperatures  and  voltages. 

Port  address  0x40  provides  access  to  the  bubble  memory.  There  are  8192  pages 
of  64  bytes  per  page.  Pages  of  the  bubble  memory  can  be  specified  at  random  by  num- 


7  The  term  "port”  is  somewhat  ambiguous.  The  NSCSIOA  reference  manual  [Ref.  llj  refers 
to  a  collection  of  pins  within  an  .NSCSIOA  integrated  circuit  as  a  port.  This  particular  desice 
contains  three  ports:  A,  B  and  C.  In  common  parlance,  however,  the  term  port  refers  to  a  par¬ 
ticular  address  in  the  input -output  address  space  (1,0  space)  of  the  Z-SO.  This  space  spans  ad¬ 
dresses  from  0x00  through  Oxff.  We  might  say,  for  example,  that  we  perform  an  input  operation 
from  port  Ox  la.  This  is  equivalent  to  sa\ing  we  input  a  b>1e  (character)  from  I  O  space  address 
Ox  la.  We  shall  seldom  attempt  explicitly  to  state  which  use  is  intended.  The  meaning  may  gener¬ 
ally  be  ascertained  from  the  context. 

8  See  the  discussion  on  hexadecimal  notation  in  the  Glossary. 
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bers  from  0  through  8191.  Port  address  0x41  provides  control  information  for  this 
memorv'  device. 

The  bubble  memory’s  reset  line  should  be  brought  low  by  placing  a  0  in  bit  5 
of  port  Cj  before  applying  power  to  or  removing  power  from  the  bubble  memory.  It  is 
important  to  wait  at  least  50  ms  after  applying  power  before  attempting  to  initialize  the 
bubble  memory  [Ref.  1:  Chapter  4,  p.  3). 

Power  can  then  be  applied  to  the  bubble  memorv'  by  putting  a  1  in  bit  4  of  port 
Cj.  Putting  a  0  there  removes  power. 

Details  of  the  operation  of  this  memory  and  the  meaning  of  the  control  byte 
information  are  in  [Ref  1].  We  describe  the  manner  in  which  we  have  progranuned  the 
bubble  memory  to  support  the  Vibro-acoustic  Experiment  in  Section  A.  Major  Sub¬ 
routines  and  Functions  on  page  108. 

4.  Real  Time  Clock 

A  National  Semiconductor  M.M58167A  real  time  clock  makes  it  possible  to  re¬ 
cord  in  the  log  of  events  the  dates  and  times  of  all  actions  taken.  We  also  use  this  device 
to  lintit  the  amount  of  time  the  control  program  waits  for  various  events  to  occur.  If  the 
event  does  not  occur  for  some  reason,  the  control  program  decides  to  stop  waiting. 

For  example,  once  the  Auxiliar>-  Power  Units  (APUs)  are  detected,  there  is  a 
window  of  about  seven  minutes  in  length.  If  launch  docs  not  occur  within  this  window, 
the  launch  will  be  scrubbed  since  the  APUs  will  no  longer  have  sufficient  fuel.  We  can 
therefore  regard  the  experiment  as  having  been  aborted  if  this  amount  of  time  passes 
without  a  launch.  We  use  the  real-time  clock  to  detect  the  passage  of  this  period  of  time. 

5.  RS-232C  Serial  Input/Output  Port 

An  RS-232C  interface  provides  communication  with  a  serial  device  such  as  a 
terminal.  This  makes  it  feasible  to  monitor  and  control  the  system  on  the  ground.  By 
connecting  a  terminal  to  this  interface,  the  user  has  access  to  an  extensive,  menu-driven 
diagnostic  subsystem.  (This  menu  subsystem  is  dormant  if  there  is  no  terminal  at¬ 
tached.)  No  intelligence  currently  is  required  on  the  part  of  the  terminal:  it  is  purely  a 
display  device.9  Port  address  OxeO  holds  control  information  to  and  from  the  serial  de¬ 
vice.  Port  address  OxcO  funnels  data  either  to  or  from  the  device.  Table  1  on  page  14 
shows  the  use  of  the  bits  of  the  control  port. 

9  Mr.  David  Rigmaiden  of  the  Space  Systems  Academic  Group  at  the  Naval  Postgraduate 
School  has  proposed  encoding  the  diagnostic  messages  and  using  an  intelligent  terminal  to  display 
the  corresponding  human-readable  messages.  However,  no  one  has  yet  done  any  work  on  this. 
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If  there  is  a  terminal  connected  to  the  RS-232C  Serial  port  at  addresses  Oxco 
and  OxeO,  then  bit  3  of  port  C,  will  be  a  1.  This  permits  the  control  program  to  distin¬ 
guish  diagnostic  operation  on  the  ground  (when  there  will  be  a  terminal  attached)  from 
actual  performance  of  the  experiment  (when  there  will  not  be  a  terminal  attached.)  As 
can  be  seen  in  Figure  1  on  page  11,  the  Vibro-acoustic  Experiment  will  not  use  a  ter¬ 
minal  when  it  is  in  space. 


Table  1.  ASSIGNMENT  OF  BITS  IN  THE  RS-232C  SERIAL  INTERFACE 
PORT:  This  port  uses  address  OxOe  for  control  information  and  O.xOc  for 
data. 


Bit 

Direction  of 
Data  Flow 

Meaning 

0 

Input 

0  if  the  attached  device  can  accept  output  infor¬ 
mation.  1  otherwise. 

1 

Input 

1  if  the  attached  device  has  data  available,  0  oth¬ 
erwise. 

B.  ADDITIONAL  CONTROLLER  HARDWARE 

The  Vibro-acousti.  '^.periment  uses  several  subsystems  which  are  not  a  part  of  the 
standard  controlk..  Tost  of  these  subsystems  appear  to  the  right  of  the  microprocessor 
in  the  block  diagram  in  Figure  1  on  page  II.  The  only  one  which  does  not  is  the  Power 
Control  Subsystem,  which  is  drawn  below  the  microprocessor.  These  subsystems  have 
the  following  functions: 

1.  Analog-to-digital  Converter  Subsystems 

Three  A,  D  converters  convert  the  analog  acoustical  signal  detected  by  a  set  of 
three  microphones  into  the  digital  format  required  by  the  Solid  State  Data  Recorder 
(SSDR).  The  design  and  operation  of  the  SSDR  is  provided  in  [Ref  9]. 

2.  Solid  State  Data  Recorder  (SSDR) 

The  SSDR  is  comparable  in  function  to  a  conventional  reel-to-reel  tape  re¬ 
corder.  Unlike  a  standard  tape  recorder,  it  is  not  limited  to  sequential  operation;  it  can 
access  data  randomly.  The  operation  of  the  SSDR  is  more  fully  described  in  [Ref  8]. 

To  issue  a  command  to  the  SSDR,  place  its  code  in  port  A,  on  NSC810A  #1. 
located  at  1,0  space  addresses  0x00  through  0x19.  The  SSDR  will  place  a  status  code 
reflecting  its  operating  state  in  port  Aj .  Table  4  on  page  17  defines  the  command  codes 


Table  2.  BIT  ASSIGNMENTS  FOR  READING  POWER  SUBSYSTEM  RELAY 


SETTINGS:  The  position  of  relays  may  be  determined  by  reading  port 
Bj  (on  NSC810A  ?^2),  which  is  located  at  I  O  space  addresses  0x20  through 
0x39. 


Bit 

Direction 
of  Data 
Flow 

Value 

Meaning 

0 

Not  used. 

1 

Input 

1 

The  Solid  State  Data  Recorder  (SSDR)  is  on 

0 

The  SSDR  is  off. 

2 

Input 

1 

The  Voltage  Controlled  Oscillator  (VCO)  is  oIT 

u 

It  is  off. 

j 

Input 

1 

The  Analog  to  Digital  Conversion  (A  D)  cir¬ 
cuit  is  on. 

0 

It  is  off. 

4 

Input 

1 

The  .Matched  Filter  .  Vibration-activated 

Launch  detector,  and  Barometric  Pressure 
Switches  are  on. 

0 

It  is  oir 

5 

Input 

1 

The  heater  circuit  is  on. 

0 

It  is  off. 

for  the  SSDR.  Table  5  on  page  17  defines  the  status  codes  the  SSDR  can  return  to  the 
control  program.  The  following  SSDR  commands  are  of  particular  note: 

Sweep  Record  12.5  minutes  of  pre-determined  frequencies  emitted  by  the  Voltage 
Controlled  Oscillator  (VCO)  prior  to  launch. 

Scroll  Record  up  to  55  seconds  of  ambient  noise  during  the  five  minutes  or  so 
between  the  time  the  Auxiliary-  Power  Units  (APU's)  come  on  and  the  time 
of  launch.  In  this  mode,  the  SSDR  will  continually  re-use  the  same  portion 
of  SSDR  memory.  There  are  two  sections  of  memory  devoted  to  this  pur¬ 
pose,  and  use  alternates  between  them.  Each  can  hold  up  to  55  seconds  of 
ambient  noise.  When  the  SSDR  is  commanded  to  enter  launch  mode,  the 
memory  section  currently  in  use  will  be  filled  and  then  the  SSDR  will  switch 
over  to  that  section  of  memory  devoted  to  recording  post-launch  noise. 

Launch  The  experiment’s  control  program  orders  the  SSDR  to  enter  launch  mode 
as  soon  as  the  Space  Shuttle  launches.  This  mode  lasts  for  two  minutes, 
which  is  about  the  time  it  takes  to  evacuate  the  air  from  inside  the 
shuttle’s  cargo  bay.  During  this  mode,  the  SSDR  records  ambient  noise. 
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Table  3.  BIT  ASSIGNMENTS  FOR  CONTROLLING  POWER  SUBSYSTEM 
RELAYS:  Relays  may  be  controlled  through  port  B,  (on  NSCSIOA  #1), 
which  is  located  at  I  O  space  addresses  0x00  through  0x19. 


Direction 
of  Data 
Flow 


Output 


Output 


Output 


Output 


Output 


Output 


Value  Meaning 


Turn  on  the  relays  specified  in  the  other  bit 
positions. 


Turn  off  the  relays  specified  in  the  other  bit 
positions. 


Operate  the  Solid  State  Data  Recorder 
(SSDR). 


Do  not  operate  the  Solid  State  Data  Recorder 
(SSDR). 


Operate  the  Voltaae  Controlled  Oscillator 
(VCO). 


Do  not  operate  the  Voltage  Controlled 
Oscillator  (VCO). 


Operate  the  Analog  to  Digital  Conversion 
(.-\  D)  circuit. 


Do  not  operate  the  Analog  to  Digital  Conver¬ 
sion  (A  D)  circuit. 


Operate  the  .Matched  Filter  (including 
accelerometer  and  barometric  switch). 


Do  not  operate  the  .Matched  Filter. 


Select  the  heater  circuit. 


Do  not  select  it. 


.As  can  be  seen  in  the  flowchart  in  Figure  22  on  page  50,  most  of  the  experiment 
is  devoted  to  the  operation  of  the  SSDR,  that  is,  to  placing  it  in  the  mode  appropriate 
for  the  current  phase  of  the  Space  Shuttle’s  mission. 

3.  Matched  Filter 

As  mentioned  in  Section  2.  Detection  of  the  Auxiliarx'  Power  Units  (APUs) 
on  page  4,  a  matched  filter  will  detect  the  characteristic  600  Hz  signature  of  the  APUs. 
This  device  will  place  a  1  in  bit  0  of  port  C,  if  a  detection  occurs.  Normally  it  leaves  a 
0  there.  Table  6  on  page  18  shows  the  uses  of  all  the  bits  of  Port  C,.  The  matched  filter 
is  described  in  Chapter  III.  THE  .MATCHED  FILTER  on  page  21. 
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Table  4.  SSDR  COMMAND  CODES;  Commands  are  issued  by  writing  them  to 
_ port  .4,  on  NSC810  j?l.  located  at  1  O  space  addresses  0\00  through  0x19. 


Code 

Value 

Meaning 

STANDBY 

0x01 

Commands  the  SSDR  to  cease  all  operations  and 
await  further  commands. 

SWEEP 

0x02 

Conamands  the  SSDR  to  enter  sweep  mode. 

Enough  memory  is  available  for  holding  holding 
12.5  minutes  of  noise  generated  by  the  VCO. 

SCROLL 

0x04 

Commands  the  SSDR  to  enter  scroll  mode. 

Enough  memory  is  available  for  holding  30  sec¬ 
onds  of  ambient  noise. 

LAUNCH 

0.x08 

Commands  the  SSDR  to  enter  launch  mode. 
Enough  memory  is  available  for  holding  two 
minutes  of  ambient  noise. 

RECORD 

0x10 

Commands  the  SSDR  to  start  recording  noise. 

This  is  analagous  to  the  RECORD  button  on 
conventional  tape  recorders. 

PLAYBACK 

0x20 

Commands  the  SSDR  to  play  recorded  data  hack. 
This  mode  is  analogous  to  the  PLAY  button  on 
conventional  tape  recorders. 

Table  5,  SSDR  STATE'S  CODES:  Status  codes  may  be  obtained  by  reading  them 
from  port  A:  on  NSCSIO  #2.  located  at  I  O  space  addresses  0x20  through 
0\}9. 


Code 

Value 

Meaning 

OPCOMP 

0x40 

Shows  that  the  SSDR  has  completed  the  last 
conunand  it  received. 

NORMOP 

OxSO 

Shows  that  the  SSDR  is  operating  normally. 

4.  Voltage  Controlled  Oscillator  (VCO) 

The  purpose  of  the  VCO  is  to  irradiate  the  shuttle’s  cargo  bay  with  sound  of  a 
predetermined  frequency  during  the  sweep  phase.  This  is  done  by  applying  power  to  a 
loudspeaker.  The  VCO  is  designed  to  step  up  in  frequency  from  35  Hz  through  785  Hz 
in  1  Hz  steps.  By  recording  the  echoes,  subsequent  analysis  will  permit  a  comparison 
of  the  acoustical  response  of  the  pure  tone  to  that  of  the  noise  generated  during  launch. 

5.  Vibration-activated  Launch  Detector 

This  circuit  is  mounted  on  the  same  circuit  board  as  the  matched  filter.  Its 
purpose  is  to  enable  the  control  program  to  detect  a  launch,  and  so  enable  it  to  com- 
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Table  6.  BIT  ASSIGNMENTS  IN  PORT  C,  OF  NSC810A  #1 


Bit 

Direction 
of  Data 
Flow 

Value 

Meaning 

0 

Input 

1 

Detection  of  the  Auxiliarv'  Power  Units  (APUs) 
has  occurred. 

0 

Detection  of  the  Auxiliarv’  Power  Units  (APUs) 
has  not  occurred. 

I 

Input 

1 

The  Vibration-activated  Launch  Detector  has 
detected  a  launch. 

0 

The  Vibration-activated  Launch  Detector  has 
not  detected  a  launch. 

2 

Input 

1 

One  of  the  barometric  pressure  switches  has 
detected  a  launch. 

0 

Neither  barometric  pressure  switch  has  de¬ 
tected  a  launch. 

3 

Input 

1 

No  terminal  is  connected  to  the  port. 

0 

A  terminal  is  connected  to  the  RS-232C  serial 
interface  port. 

4 

Output 

1 

Order  the  power  subsystem  to  change  the 
states  of  the  relays  specified  in  the  command 
at  port  B, 

0 

Do  not  change  the  states  of  the  relays. 

Not  used. 

mand  the  Solid  State  Data  Recorder  to  enter  launch  mode.  It  will  set  bit  1  of  port  C, 
high  when  it  detects  a  launch  (see  Table  6  on  page  18).  Even  if  the  matched  filter  never 
detects  the  APL's.  detection  of  launch  will  still  cause  the  control  program  to  force  the 
SSDR  into  launch  mode. 

6.  Barometric  pressure  switches 

On  the  same  circuit  board  as  the  matched  filter  there  are  two  barometric  pres¬ 
sure  switches  connected  in  a  redundant,  parallel  configuration.  These  switches  serve  as 
a  backup  for  the  Vibration-activated  Launch  Detector.  Either  one  of  them  will  place  a 
high  voltage  in  bit  2  of  port  C,  (see  Table  6)  when  pressure  drops  below’  27.9  inches  of 
mercur}'.  This  pressure  corresponds  to  an  altitude  between  1500  feet  and  2000  feet  when 
the  lowest  barometric  pressures  on  record  at  Cape  Canaveral  are  present.  In  general, 
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Table  7.  BIT  ASSIGNMENTS  IN  PORT  Q  OF  NSC810A  #2 


Bit 

Direction 
of  Data 
Flow 

i 

Value 

1 

Meaning 

0 

Output 

1 

Operate  the  heater  subsystem. 

0 

Do  not  operate  the  heater  subsystem. 

1 

Not  used. 

2 

Not  used. 

3 

Input 

1 

Analog  to  digital  conversion  is  complete.  This 
refers  to  the  On-board  A,  D  Converter  {see 
Figure  20  on  page  48). 

0 

1 

Analog  to  digital  conversion  is  not  yet  com¬ 
plete. 

4 

Output 

1 

Apply  power  to  the  bubble  memory. 

0 

Do  not  apply  power  to  the  bubble  memory. 

1 

Do  not  apply  a  reset  signal  to  the  bubble 
memory.  This  is  the  normal  setting. 

5 

Output 

0 

.Apply  a  reset  signal  to  the  bubble  memoiy. 

This  must  be  done  while  power  is  applied  to 
or  removed  from  it.  Once  the  power  has  been 
switched  on  or  off,  the  reset  line  can  be  re¬ 
turned  to  0. 

the  corresponding  altitude  will  be  somewhat  higher  than  this  since  barometric  pressures 
will  generally  not  be  at  their  lowest  when  NASA  launches  a  Space  Shuttle. 

7.  Heater  Circuit 

The  purpose  of  the  heaters  is  to  maintain  the  temperature  of  the  controller’s 
bubble  memory  module  at  or  above  lO’C  during  operation,  and  above  — 20°C  otherwise. 
To  do  this,  there  are  heater  strips  attached  to  the  bubble  memory  module.  To  turn  on 
the  heaters,  the  control  program  places  a  1  in  bit  0  of  port  Cj.  It  puts  a  0  there  to  turn 
them  off.  Insufficient  power  is  available  to  heat  all  the  bubble  memories  in  the  Solid 
State  Data  Recorder  (SSDR).  If  the  contents  of  the  log  are  saved,  however,  it  should 
at  least  be  possible  to  ascertain  the  c^use  of  the  loss  of  acoustic  data  in  the  SSDR. 

8.  Power  Control  Subsystem 

Three  batteries  of  dry  cells,  each  powering  a  different  bus,  provide  power  to  the 
experiment.  Partly  in  order  to  conserve  power,  but  also  to  permit  isolation  of  subsys¬ 
tems  if  an  overheat  condition  occurs,  most  subsystems  receive  power  only  when  neces- 


sary.  The  power  subsystem  includes  a  relay  for  each  of  these  other  subsystems.  By 
writing  appropriate  commands  to  port  B,  we  can  turn  power  to  the  relays  on  or  off. 
Table  2  on  page  15  shows  the  uses  of  the  pins  of  port  B,  for  this  purpose.  By  reading 
a  status  byte  from  Port  B,  we  can  ascertain  the  position  of  each  relay.  Table  3  on  page 
16  shows  the  uses  of  the  pins  of  port  B,  for  this  purpose. 

Let  us  designate  as  relay,  the  relay  controlled  by  pin  /  of  port  B,.lO  Valid  relays 
are  relay,  through  relay^ 

There  is  no  relay,,  since  bit  0  of  port  B,  has  a  special  purpose.  If  bit  0  of  Port 
B,  is  a  1,  then  eligible  relays  will  be  switched  on.  If  bit  0  of  Port  B,  is  a  0,  then  eligible 
relays  will  be  switched  off.  Placing  a  1  in  bit  i  of  Port  B,  makes  r,.iay,  eligible  for 
switching.  Finding  a  1  in  bit  /  of  port  Bj  means  relay,  is  on. 

Once  we  have  issued  a  command  to  alter  the  position  of  one  of  the  relays,  we 
place  a  I  in  bit  4  of  port  C,  for  20  ms  to  permit  the  command  to  take  effect,  then  put  a 
0  in  that  bit. 


10  Note  that  pin  /  of  port  B,  refers  to  the  same  relay  as  does  pin  i  of  port  Bj. 
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III.  THE  MATCHED  FILTER 


This  chapter  describes  the  design  of  a  filter  whose  purpose  is  to  detect  the  presence 
of  the  600  Hz  tone  characteristic  of  the  space  shuttle’s  Auxiliary  Power  Unit  (APU). 
This  circuit  has  not  yet  been  built  and  tested,  but  the  most  critical  sub-circuit,  the 
bandpass  filter  it  uses,  has  been  simulated.  The  results  of  the  simulation  match  the 
predicted  performance  very  closely  and  are  included  in  this  chapter. 

The  existence  of  the  tone  and  the  equation  of  a  fourth-order  elliptical  (Cauer) 
bandpass  filter  for  detecting  its  presence  are  documented  in  Jordan  [Ref  6].  While  the 
thrust  of  Jordan’s  work  was  to  develop  a  digital  filter,  the  implementation  described  in 
this  thesis  uses  analog  electronics.  This  implementation  has  the  advantage  that  it  can 
be  constructed  expeditiously  with  readily  available  components  and  requires  less  elec¬ 
trical  power.  The  digital  implementation  described  by  Jordan  requires  special  hardware 
and  components.  In  particular,  the  Intel  2920  Digital  Signal  Processor  integrated  circuit 
he  proposed  to  use  is  no  longer  in  production.  Jordan  does  propose  an  analog  imple¬ 
mentation  in  addition  to  the  digital  one.  It  requires  six  operational  amplifiers;  the  design 
proposed  here  requires  only  four,  and  so  require  less  power  to  operate.  This  is  important 
in  this  application,  since  power  is  limited. 

The  term  matched  filter  ordinarily  refers  to  a  particular  kind  of  filter  based  on 
autocorrelation.  However,  the  term  has  come  to  be  applied  incorrectly  to  the  bandpass 
filter  used  to  detect  the  application  of  power  to  the  Au.xiliary  Power  Unit.  Rather  than 
abandon  the  term  matched  filter,  which  has  become  thoroughly  entrenched  in  the  doc¬ 
umentation  of  the  Vibro-acoustic  experiment,  this  author  will  continue  to  use  (misuse) 
it  to  denote  a  narrowband  filter  whose  purpose  is  to  respond  to  the  characteristic 
600  Hz  tone  emitted  by  the  space  shuttle’s  Auxiliary'  Power  Units  beginning  about  five 
minutes  before  launch.  Figure  2  on  page  22  is  a  block  diagram  of  the  author’s  proposed 
design  for  the  matched  filter. 

A.  MICROPHONE  INPUT  STAGE 

The  microphone  input  stage  is  shown  in  Figure  3  on  page  23.  It  uses  a  Panasonic 
W.VI-063T  microphone.  A  620  Q  resistor  limits  the  current  through  the  microphone  to 
8  mA.  The  output  is  an  .AC  signal  superimposed  on  a  DC  bias. 


MATCHED  FILTER 


Figure  2.  Block  diagrnin  of  tlie  Matched  Filler. 


B.  HIGH-PASS  FILTER 

Figure  4  on  page  24  shows  the  high-pass  filter  which  connects  the  microphone  to 
the  pre-amplifier.  The  purpose  of  this  filter  is  to  eliminate  the  DC  bias  from  the  micro¬ 
phone  signal.  While  simple  AC  coupling  can  in  principle  be  provided  by  a  capacitor 
alone,  a  resistor  to  ground  must  be  included  to  provide  a  path  for  DC  from  the  non¬ 
inverting  lead  of  the  pre-amplifier.  Even  though  the  input  bias  current  of  the  OPAlll 
operational  amplifier  used  to  implement  the  pre-amplifier  is  less  than  2  pA,  if  this  were 
neglected,  charge  would  accumulate  on  the  coupling  capacitor  and  the  amplifier  would 
saturate. 

The  cut-ofiT  frequency  of  the  high-pass  filter  was  set  quite  low,  at 

F  = — ^ ^ - =  7  Hz  121 

2nRC  2a(150  Ki2)(150nF)  ^  ' 

Since  the  signal  of  interest  is  well  above  this,  at /=  600  Hz,  the  filter  introduces  no  sig¬ 
nificant  attenuation  or  phase  shilT. 
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MICROPHONE  INPUT  STAGE 


Figure  3.  The  iiiicrophune  input  stage. 

C.  PRE-AMPLIFIER 

Figure  5  on  page  25  sliows  tlie  pre-amplifier,  which  boosts  the  microphone  output 
voltage  by  a  factor  of  11  (21  dB)  using  a  non-inverting  configuration  of  the  OPA-111 
operational  amplifier.  I  he  OPA-111  has  a  very  low  noise  of  less  than  40  nV/,,  llz  at 
f  =  100  llz;  at  higher  frequencies  it  is  e\en  lower.  Ihus  the  microphone  input  is  boosted 
to  reasonable  levels  without  injecting  significant  noise  into  the  signal  and  is  bulfered 
prior  to  the  bandpass  filter. 

D.  FOURTH-ORDER,  ELLIPTICAL  (CAUER),  BANDPASS  FILTER 

Jordan  jRef  6:  p.  45]  gives  an  analog  implementation  of  a  fourth-order,  elliptical 
(Cauer),  band-pass  filter.  The  design  provided  below  reduces  the  number  of  operational 
amplifiers  by  two,  from  six  to  four. 

The  coefTicients  of  the  necessary  transfer  function  are  given  in  (Ref  6:  p.  36)  and  are: 

+  2.9587  X  10^5^  -f-  1.8991  x  lo'^ _  ^3^ 

^  ”  j**  -t-  2.4351  X  loV  -»-  2.7642  x  luV  -I-  3.3558  x  lo’s  +  1.8991  x  lo'**  ’ 

The  author  used  a  computer  program  to  find  the  roots  of  this  transfer  function,  which 
can  be  rewritten  as  follows: 
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HIGH  PASS  FILTER 

CUT-OFF  FREQUENCY  =  7  Hz 


ACOUST  IC 
SIGNAL' 

with'  50nF 
DC  OFFSET 


DC  -BLOCKED 

ACOUSTIC 

SIGNAL 


Figure  4.  High- pass  filter. 


G{s)  = 


_ (t  +  ;4.49  X  l()')(j  -y4.49  X  10’)(5  -f  y3.07  x  ll)^(t  -y3.07  x  10^) _ 

(i  +  62  -t- ;?.84  X  lo’)(i  +  62  -;3.84  x  lo’Ki  +  58.8  +  ;3.59  x  lo')(,t  +58.8  -;3.S9  x  lo’) 


(-1) 


By  multiplying  together  the  terms  containing  complex  conjugates  of  each  other,  we  ob¬ 
tain  the  biquadratic  representation  of  this  function. 

5^  +  (3.06S  X  loy  ][  J^  + (4.491  X  loy 


C(j)  = 


5^  +  (  5  +  (-’■586  X  loy  j 


L  ^  )■'  +  X  10?  J 


.  (5) 


Each  of  the  factors  in  this  expression  has  been  written  in  the  form 


5^  4-  wj 


(6) 


s  +  a>„ 


This  is  the  equation  of  a  notch  filter,  given  by  Ghausi  [Ref.  12:  p.  16|.  If  cu,  =  u)^,  then 
the  notch  filter  is  symmetric,  that  is,  the  attenuation  curve  to  the  left  and  right  of  the 
notch  frequency  is  symmetric  about  that  frequency  when  the  transfer  function  is  plotted 
on  a  logarithmic  frequency  scale.  The  first  factor  in  equation  (5)  has  a),  <  cu,.  Conse¬ 
quently,  this  factor  represents  a  high-pass  notch  filter.  The  magnitude  of  (7(s)  rises  once 
w  in  s  ^jeo  exceeds  cu,;  it  levels  off  once  <y  exceeds  w,.  By  contrast,  the  second  factor  in 
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Figure  5.  Pre-aiiipUner. 


equation  (5)  has  cu,  >  <y,.  rhorelbre,  this  factor  represents  a  low-pass  notch  filter.  I  he 
magnitude  of  G(s)  drops  once  cu  in  5  =  jeo  exceeds  oj/,  it  levels  off  once  o>  exceeds  co,.  A 
low-pass  notch  filter  and  a  high-pass  notch  filter  placed  in  cascade  form  a  bandpass  filter 
if  suitable  choices  for  co,  and  co,  are  made  in  each  case. 

It  can  be  dilficult  to  implement  cascaded  filters  successfully.  However,  the  cascade 
filter  is  very  attractive  due  to  its  simplicity,  and  for  this  reason  we  have  employed  it  here. 
1  he  design  presented  has  been  simulated  and  so  we  believe  it  would  be  quite  straight¬ 
forward  to  implement  it  in  hardware. 

The  three  forms  of  notch  filter  and  the  bandpass  filter  formed  by  cascading  a  low- 
pass  and  a  high-pass  notch  filter  arc  shown  in  Figure  9  on  page  29.  Tliree  of  these 
curves  were  calculated  by  computer  from  the  factors  in  the  transfer  function  given  in 
equation  (5).  The  symmetrical  notch  filter  transfer  function  plotted  in  the  figure  is  an 
e.xample  of  what  results  from  equation  (6)  when  co,  =  co,.  It,  too,  was  calculated  by- 
computer  from  the  transfer  function.  When  the  high-pass  notch  filter  is  multiplied  by 
(put  in  cascade  with)  the  low-pass  notch  filter,  the  bandpass  filter  shown  in  the  figure 
results.  By  using  asymmetrical  notch  filters,  as  opposed  to  synunctrical  ones,  we  can 
obtain  high  gain  in  the  passband.  In  this  region  both  notch  filters  have  high  gain  and 
so  reinforce  one  another. 


Figvire  6.  Magnitude  of  the  transfer  function  of  the  elliptical  bandpass  filter. 


The  transfer  function  for  equation  (5)  is  plotted  separately  in  figure  6  on  page  2G; 
this  plot,  too,  was  generated  by  computer.  1  he  advantage  to  writing  the  equation  for 
the  elliptical  band-pass  filter  in  the  form  of  equation  (5)  is  that  it  is  a  comparatively 
simple  matter  to  implement  biquadratic  filter  sections  using  operational  amplifiers;  by 
cascading  these  sections,  the  entire  transfer  function  can  be  implemented.  Again,  it  can 
be  dilficult  to  implement  this  scheme. 

Figure  7  on  page  27  shows  a  schematic  for  a  generalized  biquadratic  filter  using  two 
operational  amplifiers.  The  blocks  labeled  with  the  letter  “Y"  represent  admittances. 
The  design  equations  for  these  two  filter  sections  are  derived  in  APPliNDIX  A.  Deri¬ 
vation  of  Design  Equations  for  the  Matched  Filter  on  page  71.  For  the  high-pass  notch 
filter,  they  are 
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r  0  U  R  T  H -  0  R  D  E  R  ELLIPTIC 
BANDPASS  FILTER 


GAIN  =  30  dB  AT  f  :  600  Hz 
ATTENUATION  =  0  dB  AT  f  <  500  Hz  AND  (  >  700  Hz 
3  dB  BANDWIDTH  =  50  Hz 


Figure  8.  A  fourth-order,  elliptic  bandpass  filter  with  Q  =  12:  It  provides  30  dlJ 
of  attenuation  outside  the  passband. 
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BP  'K'Wl 


Figure  9.  Notch  filters:  Synunetric,  low-pass,  and  higl:-pass  notch  filters;  and  a 
bandpass  filter  formed  from  a  low-pass  and  a  high-pass  notch  filter  in 
cascade. 
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(14) 


R  = 


(15) 


For  the  high-pass  notch  filter,  o),  =  3.068  x  10^  co,  =  3.586  x  10^ ,  and  Q,  =  30.5.  Hence 

Q 

7“  =  8.176.  (16) 


If  we  make  the  arbitrary  choice  0^=  10m  F,  then  we  get  C,  =  1.22  mF  ,  R  =  27.9  £2, 
=  Ri  =  100  KQ,  Z,  =  i?i  =  818  KQ  ,  and  <2,R  =  851  £2.  Note  that  Zi  is  a  resistor 
whose  magnitude  in  ohms  is  the  reciprocal  of  the  magnitude  of  C,  in  farads.  Similarly, 
Z3  is  a  resistor  whose  magnitude  in  ohms  is  the  reciprocal  of  the  magnitude  of  Q  in 
farads.  The  apparently  arbitrary  choice  for  C4  was  actually  not  random.  This  circuit 
must  be  made  with  components  whose  stability  is  high  to  minimize  changes  in  per¬ 
formance  due  to  changes  in  temperature.  Capacitors  with  low  temperature  coefficients 
are  available  in  polystyrene  up  to  values  of  10  mF.  Using  this  value  for  Q  allows  /?,  not 
to  be  too  big,  and  R  not  to  be  too  small. 

For  the  low-pass  notch  filter,  the  design  equations  are 


=  T5  =  -4-<>Z,  =Z5  =  /?i, 

(17) 

1  =  1^7  =  sC<^Z2  =  Z7  = 

(18) 

=  F4  =  0Z3  =  Zt  =  Ra 

(19) 

Yd  =  0<»'Z^  =  00 

(20) 

~  QpR^  ~ 

(21) 

(22) 

30 


(23) 


C  =  — ^ — 

For  the  low-pass  notch  filter,  w,  =  4.491  x  10’ rad/s,  co,  =  3.843  x  10’ rad/s,  and 
Q,  =  31.0.  So 

-^=  11.35.  (24) 

If  we  arbitrarily  pick  =  1  Ki2,  then  /?.  =  11.4  KQ,  C=  260  nF,  and  =31  K  Q. 
Figure  8  on  page  28  shows  the  complete  bandpass  filter.  We  have  used  the  LF444  Quad 
Low  Power  JFET  Input  Operational  Amplifier.  It  has  an  extremely  low  input  bias  cur¬ 
rent  of  50  pA  at  most,  and  only  35  nV/^  Hz  noise  voltage. 

We  simulated  th^*  frequency  response  of  this  filter  using  Micro-Cap  111  [Ref.  13J.11 
We  found  that  it  performed  almost  exactly  as  predicted.  Figure  10  on  page  32  is  a  plot 
generated  by  Micro-Cap  111  from  its  simulation.  By  comparing  this  plot  with  that  gen¬ 
erated  from  the  transfer  function  in  Figure  6  on  page  26,  we  see  that  the  only  departure 
from  the  predicted  performance  is  a  slight  asymmetry  in  the  ripple  in  the  passband. 
Since  we  are  concerned  only  with  detection  of  the  .Auxiliary  Power  Units'  acoustic  sig¬ 
nature,  and  not  with  faithful  reproduction,  this  is  not  a  matter  for  concern.  The  center 
of  the  passband  and  the  location  of  the  upper  and  lower  notch  frequencies  are  at  the 
predicted  frequencies.  The  gain  in  the  passband  also  is  as  predicted.  The  simulation 
results  are  strong  evidence  of  the  correctness  of  the  analysis  and  the  feasibility  of  the 
design. 

The  operational  amplifier  in  the  Pre-amplifier  is  an  OPAl  1 1.  Its  output  impedance 
is  100  £2.  The  input  impedance  of  the  bandpass  filter  is  well  above  10  k£2  throughout 
the  passband.  The  bandpass  filter  therefore  does  not  provide  a  significant  load  on  the 
Pre-amplifier,  and  so  the  simulation  results  can  be  considered  to  be  quite  accurate,  even 
though  they  w^ere  produced  with  an  assumption  of  zero  output  impedance  from  the 
Pre-amplifier. 


1 1  In  the  simulation,  we  used  two  LF442  operational  amplifier  packages  instead  of  a  single 
LF444  operational  amplifier  package.  These  two  packages  provide  operational  amplifiers  with 
identical  electrical  characteristics,  wluch  justifies  the  substitution  made. 
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Figure  10.  Frequency  response  of  (lie  simulated  bandpass  filler:  This  plot  was 
obtained  using  Micro-Cap  HI  (Ref.  13).  I  he  phase  response  also  is 
shown.  It  is  the  curve  with  the  staircase-like  appearance.  Ihe  gain 
response  is  nearly  identical  with  that  generated  by  computer  and  shown 
in  Figure  6  on  page  26. 

E.  ADJUSTABLE  GAIN 

Figure  1 1  on  page  33  shows  how  a  single  LF4d4  operational  amplifier  is  configured 
as  a  non-inverting  amplifier  of  variable  voltage  gain  up  to  28  (29  dU).  The  gain  is  to  be 
adjusted  so  that  the  strongest  output  signal  has  3  V  pcak-to-peak.  This  maximum  signal 
is  that  which  exists  when  the  Auxiliary  Power  Unit  outputs  its  characteristic  tone. 

F.  FULL-WAVE  RECTIFIER 

Figure  12  on  page  34  shows  the  design  of  a  full-wave  rectifier.  It  converts  the  600 
IIz  tone  adnritted  by  the  band-pass  filter  into  a  fluctuating  direct  current  signal.  I  liis 
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AMPLIFIER 

GAIN  <  28 

AC  COUPLING  AT  OUTPUT  HAS  A 
16  Hz  CUTOFF  FREQUENCY 


Figure  11.  AinpUrier  providing  a  variable  voltage  gain  up  to  28  =  28.9  dB. 

circuit  is  modified  from  an  absolute  value  circuit  provided  by  Jung  (Ref  14:  pp.  236-237J. 
It  operates  as  follows: 

1  he  inverting  terminal  of  both  operational  amplifiers  is  at  virtual  ground.  There¬ 
fore,  on  the  positive  cycle  of  the  incoming  signal,  current  passes  through  resistor  to 
the  inverting  input  of  the  first  operational  amplifier.  This  current  is  unable  to  enter  the 
operational  amplifier  because  of  its  extremely  large  input  impedance;  nor  can  it  pass 
through  diode  Z?,  .  since  that  diode  will  only  pass  current  in  the  other  direction.  Con¬ 
sequently,  it  passes  through  resistor  /?,.  At  point  a,  the  voltage  is  the  negative  of  the 
input  voltage.  The  same  amount  of  current  Hows  through  resistor  Ry  Resistor  Rt  has 
only  half  the  resistance  of  R,  ,  so  it  draws  twice  the  current  that  resistor  R^  can  supply. 
The  balance  comes  through  resistor  R,.  This  causes  the  output  of  the  second  operational 
amplifier  to  match  that  of  the  input  to  the  circuit.  So  during  the  positive  cycle  of  the 
input,  the  input  voltage  is  duplicated  at  the  output. 

On  the  negative  cycle,  the  two  diodes  serve  to  keep  the  voltage  at  point  a  at  ground 
potential.  This  eliminates  all  current  through  resistors  and  R^ .  1  he  efi'ect  is  the  same 
as  if  the  first  operational  amplifier  were  removed  entirely.  1  he  second  operational  am¬ 
plifier  is  then  in  the  usual  configuration  for  inverting.  1  he  inverse  of  the  negative  input 
signal  is,  of  course,  a  positive  signal. 
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Figure  12.  Full-wave  rectifier. 


In  sununary,  whether  the  input  is  positive  or  negative,  the  output  is  the  absolute 
value  of  the  input. 

G.  LOW-PASS  FILTER 

The  signal  out  of  the  rectifier  has  a  fundamental  frequency  of 
2  X  600  Hz  =  1200  Hz  and  this  is  superimposed  on  a  DC  voltage  derived  as  follows: 


v(/)=  rsin(2;t//) 
=  r'sin(ft;/) 


(25) 
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Generalized  Second-Order 
Low-pass  Filter  Using  One  OPAMP 


V 

OUT 


Figure  13.  A  general  second-order,  single  operational  amplifier,  lou-pass  filter. 
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Figure  14.  Second-order,  lou-pass  filter. 


(26) 
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The  signal  into  the  filter  has  a  peak  amplitude  of  1.5  V,  Application  of  this  formula 
gives  =  0.955  V.  This  is  the  amplitude  of  the  strongest  signal  we  expect  to  receive 
from  the  Auxiliary  Power  Unit. 

The  low-pass  filter  which  follows  the  rectifier  is  designed  to  have  a  cut-off  frequency 
of/t  =  5  Hz.  This  frequency  is  well  below  the  fundamental  frequency  of  1200  Hz  passed 
by  the  rectifier.  As  a  consequence,  only  the  average  signal  we  have  just  derived  will 
be  present  at  the  output. 

The  circuit  is  based  on  the  general  circuit  showm  in  Figure  13  on  page  35.  The  de¬ 
sign  equations  for  this  circuit  are  derived  in  APPENDIX  A.  Derivation  of  Design 
Equations  for  the  .Matched  Filter  on  page  72  and  are  reproduced  here. 

C,  =  4Qep  (27) 


R,  =  R-,  =  R  —  • 


"pv'CiQ 


(28) 


In  this  application,  we  are  not  concerned  with  the  phase  of  the  signal.  Therefore  it  is 
reasonable  to  seek  a  ma.\imally  flat  transfer  function.  To  do  this,  wx  implement  a 
second-order  Butterworth  filter,  for  which 


Q, - 0.707. 

V  ^ 

Given  our  nominal  cut-off  frequency/ =  5  Hz,  we  arbitrarily  choose  Cj  =  220  nF.  We 
get  C,  =  440  nF,  and  R  =  102.3  kD.  Since  the  cut-off  frequency  is  not  critical,  we  can 
pick  the  more  convenient  component  values  C,  =  470  nF  and  R  =  100  kD.  The  resultant 
cut-off  frequency  is  /  =  4.9  Hz  and  =  0.731.  Since  the  purpose  of  this  low-pass  filter 
is  to  find  the  average  of  the  rectified  600  Hz  tone,  this  deviation  from  the  design  pa¬ 
rameters  is  quite  acceptable  as  the  cut-off  frequency  still  is  w’ell  below  the  fundamental 
frequency  of  1200  Hz  created  by  full-wave  rectification  of  the  600  Hz  tone. 

The  chief  benefit  provided  by  this  filter  is  a  roll-off  of  40  dB/decade  when 
/>/  =  4,9  Hz.  This  amounts  to  96  dB  attenuation  when/—  12(X)  Hz,  which  is  ample 
to  suppress  the  AC  component  in  the  signal  out  of  the  full-wave  rectifier.  Figure  14  on 
page  36  shows  the  component  choices  and  circuit  for  the  second-order  low-pass  filter. 


Figure  IS.  Threshold  detector. 


H.  THRESHOLD  DETECTOR 

Figure  15  on  page  38  sliows  the  design  of  a  threshold  detector.  There  is  some  evi¬ 
dence  that  other  sources  of  6<X)  Hz  signals  that  might  be  present  simultaneously  will  be 
15  dB  below  this.  The  voltage  which  is  15  dB  below  0.955  V  is  0.170  V.  Any  signal 
which  e.Kceeds  the  0.170  V  threshold  just  derived  should  cause  the  threshold  detector  to 
signal  that  a  sufficiently  strong  600  Hz  signal  is  present.  Presumably  this  signal  is  from 
the  Auxiliary  Power  Unit.  I  he  threshold  detector  uses  an  LM358  operational  amplifier. 
This  device  requires  only  a  single  power  supply  and  it  tends  not  to  “latch  up"  wlien 
configured  as  a  comparator.  Its  output  goes  high  (to  5  V)  whenever  the  threshold  is 
exceeded.  Othervvisc,  its  output  is  held  low  (at  ground). 

I.  RESETTABLE  PULSE  COUNTER 

Figure  16  on  page  39  shows  the  Resettable  Pulse  Counter.  Its  purpose  is  to  signal 
the  presence  of  a  6(X)  llz  signal  from  the  Auxiliary  Power  Unit  if  it  has  been  contin¬ 
uously  present  for  73. Is.  Spurious  signals  with  a  component  at  f  =  600  Hz  may  be 
present  intermittently.  We  do  not  expect  them  to  be  continuously  present  at  levels  more 
than  15  dB  below  that  of  the  strongest  signal  expected  from  the  Auxiliary  Power  Unit. 
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Figure  16.  Resettable  Pulse  Counter:  I  his  circuit  decides  that  the  APUs  are  on 


il'it  gets  a  signal  I'roin  the  threshold  detector  for  73.1  s. 


Consequently,  the  Resettable  Pulse  Counter  has  the  cflect  of  eliminating  False  triggering 
due  to  these  spurious  signals. 

Whenever  the  threshold  detector  indicates  the  presence  of  the  6U0  I  Iz  tone  charac¬ 
teristic  of  the  Auxiliary  Power  Unit,  it  produces  a  high  output.  This  signal  is  applied  to 
the  LOAD(L)  input  of  the  Resettable  Pulse  Counter.  I  his  permits  the  counter  to  begin 
marking  olT  the  pulses  which  arrive  from  the  Pulse  Generator,  described  below.  Because 
the  pre-load  inputs  A  through  D  all  are  connected  to  ground,  the  counter  will  count  from 
zero  to  15,  at  which  point  its  CO  output  will  go  high.  I  hus,  the  counter  will  permit 
sixteen  pulses  to  arrive  from  the  Pulse  Generator  before  it  goes  high.  Since  the  period 
of  these  pulses  is  T**  4.57  s,  the  output  will  go  high  if  14  x  4.57  s  =  73.1  .s  elapses. 
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Configuration  of  an  LM555  Timer 
for  Astable  Operation 


Figure  17.  Astable  operation  of  the  LM555  Tinier  to  generate  a  pulse  train. 

J.  PULSE  GENERATOR 

This  module  is  based  on  tl\e  LM555  I'imcr  integrated  circuit.  The  data  sheet  Cor  this 
circuit  provides  equations  to  permit  choosing  component  values  to  provide  the  desired 
period  and  duty  cycle.  The  duty  cycle  is  not  critical  to  this  application.  Figure  17  on  # 

page  40  shows  the  general  configuration  for  astable  operation,  which  is  the  mode  of 
operation  which  produces  a  periodic  signal.  The  design  equations  arc: 


w  =  0-693(/?^  +  Rb)C 

(30) 

^discharge  ~  0.693RgC. 

(31) 

Thus  the  total  period 

^  =  'e/iargf  +  ^discharge  =  0.693(R^  +  2Rg)C.  (32) 
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PULSE  GENERATOR 
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Figure  18.  Pulse  Generator. 


Solving  for  C  \ve  get 


1 


^  0.693(7?^  +  2/?b)C  " 


(33) 


and  the  duty  cycle 


D  = 


Rn 

Ra  ■+■  ^Rb 


(34) 


Picking  =  200  KJ2  provides  a  duty  cycle  D  •=  0.333  ,  which  is  perfectly  accepta¬ 

ble  for  this  non-critical  parameter. 

Figure  18  shows  a  Pulse  Generator  based  on  this  configuration.  This  circuit 
produces  a  regular  stream  of  square  pulses  of  period  7  =  4.57  s.  These  are  used  by  the 
Resettable  Pulse  Counter  to  measure  the  amount  of  time  when  a  reasonably  strong  600 
llz  signal  is  present. 
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K.  SUMMARY 

This  completes  the  description  of  the  somewhat  inappropriately  named  matched  fil¬ 
ter.  Simulation  of  the  bandpass  filter  used  in  the  matched  filter  has  shown  that  that  part 
of  the  design  is  correct  and  feasible.  The  implementation  and  testing  of  the  bandpass 
filter  and  the  other  components  of  the  entire  circuit  remain  to  be  done  in  the  future. 
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IV.  DESIGN  OF  THE  CONTROL  SOFTWARE 


In  describing  the  software  which  operates  the  controller  hardware,  we  shall  adopt 
the  following  conventions. 

We  will  show  variable  names  in  bold,  e.g.,  variable;  function  names  in  bold  with 
(possibly  empty)  parentheses  at  the  end,i2  e.g.,  function(),  and  constants  in  uppercase, 
e.g.,  CONSTANT. We  shall  also  use  bold  for  the  names  of  regions,  described  below  in 
Section  A.  Memory  Map.  Development  of  the  software  for  the  Vibro-acoustic  E.\per- 
iment  was  done  under  the  Microsoft  Disk  Operating  System  (MS  DOS).  Figure  35  on 
page  89  shows  how  we  arranged  the  hierarchy  of  files  containing  the  source  code,  object 
code,  header  files,  etc.  See  APPENDIX  D.  H1ER.ARCHICAL  0RGANTZ.\T10N 
OF  SOFTWARE  FILES  on  page  88  for  a  more  complete  discussion  of  this  organiza¬ 
tion. 


A.  MEMORY  MAP 

Figure  19  on  page  44  shows  the  addresses  of  the  ROM  and  RAM  in  the  computer. 
Our  NSCSOO-based  controller  provides  for  up  to  eight  EPROMs  and  ILA.Ms  in  any 
combination,  each  holding  8  KBytes.  The  wiring  of  the  printed  circuit  board  permits 
placing  a  R.AM  chip  in  any  of  the  addresses  evenly  divisible  by  0x2000  {e.g.,  O.xOOOO, 
0x2000,  0x4000,  etc.)  The  addition  of  a  jumper  wire  permits  the  R.AM  chip  to  be  re¬ 
placed  by  an  EPRO.M. 

The  NSC800  uses  the  same  architecture  as  the  Z-80  [Ref  10).  Because  the  Z-80 
architecture  causes  execution  to  begin  at  address  0x0000  whenever  power  is  applied,  it 
is  necessary  to  install  an  EPROM  at  location  0x0000.  It  was  therefore  convenient  for 
us  to  put  all  EPROMs  at  the  low  end  of  memory^  and  all  RA.Ms  at  the  high  end.  AP¬ 
PENDIX  C.  HOW  THE  UNTWARE  SOFTWARE  USES  THE  COMPUTER 
.MEMORY  on  page  86  explains  the  way  in  which  the  Uniware  C  Compiler  employs  the 
memory. 


12  According  to  custom  in  the  C  programming  language. 

13  In  C.  constants  are  declared  using  the  ^define  directive.  These  are  stored  in  various  header 
files  such  as  vibro.h. 
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0x0000 

ROM 
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0x2000 
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0x4000 
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Figure  19.  Memory  ni.ip  of  the  computer;  This  figure  shows  the  locations  of 
ROM,  RAM,  and  the  eight  software  regions.  The  ROM  and  RA.M 
addresses  are  specified  by  the  hardware  design.  1  he  addresses  of  the 
regions  are  specified  by  the  linker. 
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B.  OPERATION  OF  THE  MBRO-ACOUSTIC  EXPERIMENT 
I.  Menu-driven  Diagnostic  Program 

Some  years  ago  the  illin  Al^en  was  produced.  As  a  part  of  the  publicity  cam¬ 
paign  attending  its  release  was  the  slogan,  “In  space,  no  one  can  hear  you  scream.” 
Similarly,  when  the  Vibro-acoustic  Experiment  is  performed  in  the  Space  Shuttle,  there 
will  be  no  one  to  hear  it  scream,  that  is,  to  monitor  the  progress  of  the  experiment. 

This  is  quite  differeni  from  the  situation  on  the  grruui.  v.here  generally  there 
IS  a  monitor  attached,  and  there  is  someone  monitoring  execution  of  the  program. 
Furthermore,  there  is  a  need  on  the  ground  to  test  components  of  the  experimental 
package  without  running  the  experiment  from  start  to  finish.  For  example,  we  have 
found  it  helpful  to  be  able  to  operate  the  bubble  memor\’  module  attached  to  the  con¬ 
troller  Jiardware  in  a  manual  mode.  By  tins  means,  wc  ha\e  debugged  th.c  software  and 
ensured  tliat  it  can  operate  the  babble  memory  successfully  before  attempting  to  u^e  it 
in  our  appheation. 

An  obvious  way  to  allow  software  to  be  tested  on  the  ground  but  used  to  run 
tl'.e  expe.nment  in  space  v.'cuid  be  to  compile  a  dillcrent  program  I'or  each  purpose.  This 
is.  to  put  it  rnildiy,  a  vcr>  inconvenient  approa«.h.  Not  ■■'r.ly  must  two  distinct  programs 
be  managed,  but  assurance  that  the  diagnostic  version  works  gives  little  assurance  that 
t.he  cpcrational  one  v,  ill  -.verk.  U'e  have  elected  to  iuivc  a  sir.glc  program,  usable  under 
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3.  Power  subsystem  control.  Individual  subsystems  can  be  powered  up  or  down  under 
the  user's  control. 

4.  Bubble  memory  control.  The  bubble  memory  used  for  storing  a  log  of  events  per¬ 
formed  during  the  experiment  can  be  powered  up  or  down,  initialized,  or  tested 
under  the  user’s  control.  These  tests  are  at  a  very  low  level.  Data  stored  in  the 
bubble  memon.'  consists  of  character  strings,  and  these  are  unformatted.  The  data 
are  not  treated  as  formatted  log  entries.  14 

5.  Analog-to-Digital  (A/D)  converter  control.  Any  of  the  temperatures  and  voltages 
accessible  through  a  channel  of  the  on-board  A;  D  converter  can  be  read  under  the 
user's  control. 

6.  Running  the  experiment.  This  causes  the  Vibro-acoustic  experiment  to  be  per¬ 
formed.  The  only  difference  between  operating  the  experiment  under  menu  control 
and  operating  it  with  no  terminal  attached  is  that  with  a  terminal,  a  large  amount 
of  diagnostic  information  is  displayed  during  e.xecution.  Without  a  terminal  at¬ 
tached.  this  information  is  lost.  The  advantage  to  this  approach  is  that  if  the  ex¬ 
periment  works  on  the  ground,  we  are  assured  it  will  work  in  space,  since  essentially 
the  same  code  is  executed  in  both  cases. 

7.  Perform  port  input  and  output.  This  is  a  ver\  low-level  test.  Cliaracters  of  data  can 
be  written  to  or  read  from  a  port  at  any  address,  one  at  a  time.  This  is  helpful  in 
debugging  the  software. 

S.  Display  contents  of  the  controller's  memory.  This,  too,  is  a  very  low-lc\cl  routine 
useful  only  for  debugging. 

9.  Examine  or  change  bubble  memor}’.  These  routines  permit  the  formatted  contents 
of  the  bubble  memory  log  to  be  displayed  in  a  readable  manner  on  the  terminal. 
In  addition  to  allowing  debugging  to  be  done,  this  operation  permits  the 
experiment's  operation  to  be  tailored  in  advance. 

Each  of  these  menu  items  leads  to  a  further  menu  of  functions  to  permit  the 
operator  to  test  all  subsystems  of  the  experiment.  These  routines  are  discussed  in  detail 
in  the  software  description  contained  in  Section  A.  Major  Subroutines  and  Functions 
on  page  108. 

2.  Performing  the  Experiment 

This  section  describes  in  detail  the  steps  of  the  experiment.  These  steps  are  il¬ 
lustrated  in  the  flowcharts  contained  in  the  following  pages. 
a.  Microprocessor  Control  Program 

Flowchart  0  in  Figure  20  on  page  48  shows  the  overall  structure  of  the 
control  program.  The  program  begins  executing  when  power  is  first  applied  to  the  sys¬ 
tem.  After  initializing  the  hardware  for  proper  operation,  it  checks  to  see  whether  or 
not  there  is  a  terminal  attached.  If  not,  it  proceeds  on  the  footing  that  it  should  run  the 


14  There  are  additional  bubble  memories  within  the  Solid  State  Data  Recorder  (SSDR)  which 
are  not  tested  by  these  routines. 
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experiment,  bypassing  all  the  menu  routines.  If,  on  the  other  hand,  a  terminal  is  con¬ 
nected,  then  the  program  deduces  that  the  experiment  is  not  being  run  in  space,  where 
no  terminal  will  be  available,  and  so  it  enters  the  menu  subsystem.  The  experiment  is 
not  performed  unless  the  user  specifically  requests  this  later. 

b.  Initialize  Hardware 

Flowchart  1  in  Figure  21  on  page  49  is  a  more  detailed  look  at  block  1  of 
Flowchart  0  in  Figure  20  on  page  48.  The  first  initialization  task  to  be  performed  is  to 
let  the  programmable  input 'output  devices  know  which  data  lines  are  for  input  and 
which  are  for  output.  There  are  two  clocks  which  also  must  be  initialized.  One  of  these 
provides  a  clock  signal  for  serial  communications  at  9600  baud.  The  other  provides  a 
clock  for  conversion  of  data  from  analog  to  digital  form. 

c.  Run  the  Vibro-acoustic  Experiment 

Flowchart  2  is  shown  in  Figure  22  on  page  50.  It  is  a  more  detailed  leak 
at  block  2  of  Flowchart  0  in  Figure  20  on  page  4S. 

One  of  its  first  tasks  is  to  initialize  certain  variables  in  the  software.  It  then 
ascertains  (by  consulting  a  record  in  the  bubble  memory)  whether  the  full  experiment 
or  the  abridged  version  is  to  be  performed.  The  full  experiment  consists  of  the  sweep, 
scroll,  launch,  and  post-launch  phases  already  described  in  Chapter  1.  INTRODUC¬ 
TION  on  page  1.  fhe  scroll  phase  is  omitted  if  the  .Auxiliary  Power  Units  (.APUs)  are 
not  detected  before  the  launch  was  detected. 

In  the  abridged  experiment,  the  program  initially  checks  to  see  if  the 
barometric  switches  have  been  triggered,  which  they  would  have  been  were  the  Space 
Shuttle  already  in  space.  This  check  is  done  to  avoid  entering  record  phase  a  second 
time  when  the  space  shuttle  is  already  aloft.  Such  a  situation  might  arise  after  a  power 
fault  during  lift-off;  to  recommence  record  mode  would  erase  the  acoustic  data  recorded 
during  the  launch. 

The  next  decision  to  be  made  is  whether  or  not  to  enter  record  mode. 
Conceivably,  the  Auxiliary  Power  Units  could  be  detected  and  the  record  phase  entered 
at  some  point,  but  the  launch  might  then  be  scrubbed.  If  power  were  not  removed  from 
the  experiment,  then  the  control  flow  would  permit  record  mode  to  be  commenced  anew. 
Why  not  just  start  record  mode  again?  Operating  the  Sohd  State  Data  Recorder  with 
its  bubble  memories  consumes  considerable  power.  We  cannot  afford  to  waste  that 
power  by,  in  effect,  continuously  operating  the  recorder  unnecessarily.  The  decision  not 
to  let  this  mode  be  begun  again  until  at  least  12  hours  after  the  last  time  will  prevent  this 
from  happening.  .Also,  if  a  power  fault  occurred  after  the  record  phase  began,  we  would 
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Figure  20.  Flowchart  0:  This  is  the  highest  level  of  (lowchart  in  the  hieraicliy. 
Processing  begins  here  when  the  controller  lirst  receives  power. 


prefer  to  avoid  interfering  with  the  Solid  State  Data  Recorder  (SSDR).  which  niiglit  still 
be  operating  successfully  in  record  mode.  1  his  safeguard  will  ensure  that  such  interfer¬ 
ence  does  not  occur.  If  a  mission  is  scrubbed,  it  would  not  be  rescheduled  for  at  least 
24  hours.  The  12  hour  wait  is  long  enough  to  avoid  interfering  unduly  with  the  SSDR 
and  to  preclude  wasting  power  and  is  short  enough  to  permit  correct  operation  when  the 
launch  is  rescheduled. 

Once  either  the  Au.xiliary  Power  Units  or  any  launch  indication  are  de¬ 
tected,  record  mode  can  be  entered.  Normally,  upon  completion,  we  expect  to  be  in 
space.  In  this  case,  control  will  be  passed  to  the  post-launch  phase  of  the  mission. 
Otherwise,  the  mission  must  have  been  aborted  and  the  12  hour  wait  begins. 
d.  Initialize  Software 

Flowchart  2.1  in  Figure  23  on  page  51  is  a  more  detailed  look  at  block  2.1 
of  Flowchart  2  in  Figure  22  on  page  50.  initializing  the  software  entails  discovering 
what  the  current  status  of  the  experiment  is.  For  example,  this  might  be  the  first  time 
power  has  been  applied,  in  which  case  the  snrrp  phase  has  not  been  performed  yet,  and 
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Figure  21.  Flowchart  1:  The  flowchart  shows  the  initialization  of  hardware  and 
software  at  the  very  beginning  of  program  execution. 


the  launch  has  not  taken  place.  Or  perhaps  the  sweep  was  performed  previously,  but  the 
Space  Shuttle  still  is  on  the  ground.  This  information  was  stored  previously  in  the 
bubble  memory  log,  and  it  must  be  retrieved  before  the  controller  can  know  what  it 
should  do. 

The  controller  also  turns  off  the  Voltage  Controlled  Oscillator  for  safety 
reasons.  Because  the  speaker  connected  to  it  emits  such  a  loud  tone,  it  would  be  dan¬ 
gerous  to  allow  it  to  operate  until  the  controller  can  first  see  whether  it  has  been  begun 
once  before.  If  NASA  eventually  agrees  to  permit  the  sweep  phase  to  be  performed,  they 
will  almost  certainly  afford  us  only  one  opportunity  to  perform  it.  If  it  does  not  com¬ 
plete  successfully,  there  is  no  second  chance.  The  heater  subsystem  also  is  deactivated 
as  a  power-saving  measure  until  the  controller  can  find  out  exactly  what  to  do. 
e.  Do  Sweep 

Flowchart  2.2  in  Figure  24  on  page  52  is  a  more  detailed  look  at  block  2.2 
of  Flowchart  2  in  Figure  22  on  page  50.  If  the  sweep  phase  ever  was  started  before,  or 
if  the  launch  was  performed  previously,  the  sweep  phase  is  skipped.  Otherwise  the  con¬ 
troller  notes  in  the  bubble  memory  log  that  it  has  now  started  the  sweep  phase,  which 
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Figure  22.  Flowchart  2:  1  his  flowchart  shows  the  steps  entailed  in  both  the  full 
and  the  abridged  versions  of  the  Vibro-acoustic  Experiment. 
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Figure  23.  Flowchart  2.1:  1  his  flowchart  shows  the  steps  entailed  in  initiali;^ing 

the  software  when  the  experiment  is  performed. 


will  ensure  that  it  never  tries  to  restart  it.  1  he  controller  now  causes  echoes  of  known 
frequencies  to  be  recorded. 

The  controller  expects  to  be  informed  of  the  completion  of  the  sweep  phase. 
However,  a  13  minute  timeout  is  initiated  to  make  sure  that  tlie  controller  docs  not  wait 
forever  for  this  information. 

f.  Start  Recording  Response  at  Known  Frequencies 

Flowchart  2.2.2  in  Figure  25  on  page  53  is  a  more  detailed  look  at  block 
2.2.2  of  Flowchart  2.2  in  Figure  24  on  page  52.  It  shows  the  steps  entailed  in  initiating 
the  sweep  phase.  1  he  Analog  to  Digital  Converter  Subsystem  must  be  turned  on  first, 
since  the  converters  power  the  microphones  which  receive  the  acoustic  signal.  The 
Voltage  Controlled  Oscillator  (VCO)  can  then  be  started,  followed  by  the  Solid  State 
Data  Recorder  (SSDR).  Starting  the  SSDR  requires  first  applying  power  to  it  and  then 
commanding  it  to  enter  sweep  mode. 

g.  Stop  Recording  Response  at  Known  Frequencies 

Flowchart  2.2.4  in  Figure  26  on  page  54  is  a  more  detailed  look  at  block 
2.2.4  of  Flowchart  2.2  in  Figure  24  on  page  52.  It  shows  the  steps  entailed  in  termi¬ 
nating  the  sweep  phase.  These  steps  are  to  remove  power  from  three  subsystems:  the 
Voltage  Controlled  Oscillator  (VCO),  the  Solid  State  Data  Recorder  (SSDR)  and  the 
Analog  to  Digital  (A,'D)  Converter. 
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Figure  24. 


Flonchart  2.2:  1  his  flowchart  shows  the  steps  entailed  in  performing 
the  sweep  phase  of  the  experiment. 
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the  recording  of  known  Crcqucncics  during  the  sweep  phase  of  the  ex¬ 
periment. 


h.  Wait  for  APUs  to  Start  or  for  Launch  Indications 

Flowcliart  2.3  in  Figure  27  on  page  55  is  a  more  detailed  look  at  block  2.3 
of  Flowchart  2  in  F'igure  22  on  page  50.  fhere  arc  two  possible  indications  of  a  launch. 
One  is  a  signal  from  the  Vibration-activated  Launch  Detector  circuit.  1  he  other  is  a 
signal  from  the  barometric  switches.  If  either  of  these  is  present,  the  Hag  LAUNCHED 
is  asserted.  Otherwise,  the  controller  will  check  to  see  if  the  Auxiliary  Power  Units 
(APUs)  have  been  detected.  If  so,  the  flag  APUs  ON  is  asserted.  If  no  indications  are 
present,  the  controller  will  continue  looking  for  them  indclinitcly, 

I.  Do  Scroll 

Flowchart  2.4  in  Figure  28  on  page  56  is  a  more  detailed  look  at  block  2.4 
of  Flowchart  2  in  Figure  22  on  page  50.  It  shows  the  steps  entailed  in  performing  the 
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Figure  26.  Flowchart  2.2.4:  I  his  flowchart  shows  the  steps  entailed  in  stopping 
the  recording  of  known  frequencies  during  the  sweep  phase  of  the  ex¬ 
periment. 


scroll  pliase.  Power  is  applied  to  the  Solid  State  Data  Recorder  (SSDR),  and  it  is  then 
commanded  to  enter  scroll  mode. 

I  he  mission  will  be  scrubbed  if  no  launch  occurs  within  seven  minutes  after 
the  Auxiliary  Power  Units  are  started.  We  initiate  a  ten  minute  timeout,  which  is  con¬ 
servative.  If  at  the  end  of  ten  minutes  no  launch  indications  have  been  detected,  the 
program  aborts;  otherwise,  it  asserts  the  LAUNCHED  (lag. 
j.  Abort 

Flowchart  2.4.4  in  Figure  29  on  page  57  is  a  more  detailed  look  at  block 
2.4.4  of  Flowchart  2.4  in  F'igure  28  on  page  56.  It  shows  that  when  the  mission  is 
deemed  to  have  been  aborted,  power  is  removed  from  all  subsystems. 

A.  Do  Launch 

Flowchart  2.5  in  Figure  30  on  page  58  is  a  more  detailed  look  at  block  2..'' 
of  Flowchart  2  in  Figure  22  on  page  50.  The  flowchart  shows  the  steps  entailed  in 
performing  the  launch  phase  of  the  experiment.  The  lirst  step  is  to  determine  whether 
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Figure  27.  Flowchart  2.3:  This  flowchart  shows  the  steps  entailed  in  listening  for 
the  Auxiliary'  Power  Units  (APUs)  while  simultaneously  waiting  for  in¬ 
dications  of  a  launch. 

this  is  necessary  or  not.  If  the  launch  was  ever  determined  to  have  been  completed  in 
the  past,  the  LAUNCH  DONE  will  have  been  asserted  then.  In  this  case,  it  is  not  ap¬ 
propriate  to  perform  this  phase  a  second  time  and  so  all  the  blocks  in  this  flowchart  will 
be  skipped.  Otherwise,  the  Solid  State  Data  Recorder  (SSDR)  is  conunanded  to  leave 
scroll  mode  and  enter  launch  mode.  Within  two  minutes  of  the  time  of  launch,  there  will 
no  longer  be  any  air  in  the  Space  Shuttle’s  cargo  bay.  We  initiate  a  three  minute  timeout 
so  that,  in  the  event  that  the  SSDR  fails  to  signal  completion  of  the  launch  phase,  the 
controller  will  not  be  stuck  permanently  in  launch  mode.  1  he  controller  repeatedly 
checks  either  for  a  completion  signal  from  the  SSDR  or  for  a  timeout. 

/.  Check  for  a  Completed  Launch 

Flowchart  2.5.3  in  Figure  31  on  page  59  is  a  more  detailed  look  at  block 
2.5.3  of  Flowchart  2.5  in  Figure  30  on  page  58.  If  the  LAUNCH  DONE  Hag  ever  was 


Figure  28.  Floucliart  2.4;  1  his  flowchart  shows  tlie  steps  entailed  in  pcrforniijig 
the  scro//  phase  between  the  time  the  Auxiliary  Power  Units  (A PL's) 
start  operating  and  the  time  that  the  launch  is  detected. 

asserted,  this  block  does  nothing.  However,  if  this  flag  was  not  previously  asserted,  the 
state  of  the  barometric  pressure  switches  is  checked.  If  either  of  them  has  tripped,  wc 
have  a  positive  indication  of  launch.  It  is  then  appropriate  to  set  the  LAUNCH  DONE 
nag. 
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m.  Do  Post-launch 

Flowcliart  2.6  in  Figure  32  on  page  60  is  a  more  detailed  look  at  block  2.6 
of  I'lowchart  2  in  Figure  22  on  page  50.  It  shows  the  steps  entailed  in  performing 
post-launch  functions.  Ihesc  are  the  monitoring  functions  required  after  the  Space 
Shuttle  has  leR  the  earth's  atmosphere.  I  hc  fust  step  is  to  remove  power  from  all  sub¬ 
systems.  A  five  minute  timeout  is  then  initiated.  The  cfl'cct  of  this  is  to  permit  system 
status  to  be  recorded  every  live  minutes.  1  he  heater  subsystem  is  one  of  the  subsystems 
which  needs  monitoring.  A  check  is  done  to  ensure  that  the  launch  has  been  recorded 
as  complete.  These  two  steps  arc  repeated  cotJtinually  throughout  each  five  minute  pe¬ 
riod.  At  the  completion  of  that  period,  current  values  of  the  temperature  and  voltage 
at  various  points  are  read  and  stored  in  the  bubble  memory  log.  .A  check  also  is  made 
to  see  if  the  voltages  on  the  buses  are  too  low.  If  so,  the  post-launch  processiitg  ceases. 

n.  Monitor  Heater  Subsystem  Operation 

Flowchart  2.6.3  in  Figure  33  on  page  61  is  a  more  detailed  look  at  block 
2.6.3  of  Flowchart  2.6  in  Figure  32  on  page  60.  It  has  two  branches.  In  one,  the  tem¬ 
perature  of  the  experimental  apparatus  is  sulliciently  high,  in  which  case  the  heater 
subsystem  is  deactivated.  In  the  other  branch,  the  temperature  is  too  low'  and  the  heater 
subsystem  is  activated. 

0.  Do  Record 

Flowchart  2.7  in  Figure  34  on  page  62  is  a  more  detailed  look  at  block  2.7 
of  Flowchart  2  in  Figure  22  on  page  50.  It  shows  the  steps  entailed  in  putting  the  e.x- 
periment  into  the  record  phase.  These  steps  arc,  first,  to  put  the  Solid  State  Data  Re- 
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Figure  30.  Flowchart  2.5:  1  liis  flowcliart  sliovvs  the  steps  entailed  in  performing 


the  launch  pliase  of  the  experiment. 


corder  (SSDR)  into  the  launch  mode,  and  then  to  begin  a  20  minute  timeout,  after  whicli 
time  the  SSDR  would  have  run  out  of  memor}’  in  which  to  store  recorded  sound.  1  he 
SSDR  normally  would  inform  the  controller  that  it  has  completed  opcratioti  before  the 
timeout  occurs.  1  he  timeout  is  meant  to  permit  the  controller  to  leave  the  record  phase 
even  if  the  SSDR  fails  to  signal  completion. 
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Figure  31.  Floucliart  2.5.3:  This  flowchart  shows  the  steps  entailed  in  deciding 
whether  or  not  a  launch  has  occurred.  The  barometric  switch  is 


deemed  to  be  the  most  reliable  (and  only  convincing)  indication  of  a 
launch. 
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Figure  32.  Flowchart  2.6:  This  flowchart  shows  the  steps  entailed  in  performing 
measurements  and  monitoring  temperatures  and  voltages  after  the  ex¬ 
periment  is  complete. 
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Figure  33.  Flouclinrt  2.6.3:  Ihis  ilouchart  shows  the  steps  entailed  in  monitor¬ 
ing  the  temperatures  of  the  bubble  memory  unit  and  maintaining  that 
temperature  above  lO^C. 
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Figure  34.  Flowchart  2.7:  riiis  nowcliart  show  s  the  steps  entailed  in  pcrrorniiiig 
the  record  phase  of  the  abridged  experiment. 
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V.  HOW  TO  GET  THE  EXPERIMENT  READY  FOR  A  LAUNCH 

This  chapter  explains  what  must  be  done  prior  to  the  launch  of  the  Space  Shuttle 
to  ensure  that  the  experiment  is  performed  correctly.  The  current  status  of  the  exper¬ 
iment  is  stored  in  page  0  of  the  bubble  memory  log.  By  setting  appropriate  information 
there,  we  can  ensure  that  when  power  next  is  applied  to  the  experimental  apparatus,  the 
correct  sequence  of  steps  is  performed. 

There  are  really  two  possible  experiments  to  be  performed:  the  unabridged  exper¬ 
iment  and  the  abridged  one.  The  abridged  experiment  dispenses  with  the  sweep,  scroll, 
and  launch  phases  of  the  experiment,  replacing  them  with  a  single  record  phase.  Which 
of  these  is  to  be  run  must  be  stored  in  page  0  before  launch. 

A.  UNABRIDGED  EXPERIMENT 

Attach  a  terminal  to  the  RS-232C  interface  and  apply  power  to  the  experiment.  The 
controller  will  present  the  following  menu  on  the  terminal. 

A  Software  reset. 

B  Realtime  clock  functions. 

C  Power  relay  switching  functions. 

D  Bubble  memory  test  functions. 

E  A/D  converter  functions. 

F  Run  experiment. 

G  Perform  port  I/O. 

H  Display  contents  of  controller  memory. 

I  Examine  or  change  the  data  logged  in  the  bubble  memory. 

Z  Exit  this  menu. 

Choose  option  (I).  The  following  menu  will  be  presented  next. 

A  Display  page  0. 

B  Display  a  page  of  the  log. 

C  Alter  the  contents  of  page  0. 

Z  Exit  this  menu. 

Choose  option  (C).  The  following  menu  will  next  be  displayed. 
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A  Toggle  ' sweepstarted'  flag  from  TRUE  to  FALSE. 

B  Toggle  ' launchdone'  flag  from  TRUE  to  FALSE. 

C  Alter  value  of  next  available  page  from  0x12  =  18. 

D  Alter  value  of  next  available  half  page  from  1  to  0. 

E  Toggle  ' full_experiment'  flag  from  TRUE  to  FALSE. 

F  Specify  the  'RECORD_start_time'  (make  this  at  least  12  hours  before  the 
present  to  permit  RECORD  u  jde  to  be  initiated.  ) 

Z  Exit  this  menu. 

The  menu  may  not  look  exactly  like  this,  inasmuch  as  the  flags  and  page  numbers  may 
var>'.  The  objective,  however,  is  to  set  the  sweepstarted  flag  to  FALSE;  the  launchdone 
flag  to  FALSE;  the  value  of  the  next  available  page  to  1;  the  value  of  the  next  available 
half-page  to  0;  the  value  of  the  full_experinient  flag  to  TRUE.  The  value  of  the 
RECORD_start_time  does  not  matter  since  the  record  phase  is  not  performed  in  the 
unabridged  experiment.  If  a  value  is  already  correct,  it  may  be  left  alone.  Only  if  it 
needs  to  be  changed  must  the  corresponding  menu  choice  be  made. 

B.  ABRIDGED  EXPERIMENT 

For  the  abridged  e.xperiment,  follow  the  same  steps  as  with  the  full  experiment  with 
the  following  differences.  The  full_experiment  flag  should  be  set  to  F.ALSE,  and  the 
RECORD_start_time  should  be  set  to  some  value  at  least  12  hours  before  launch.  The 
value  of  the  sMeepstarted  flag  does  not  matter  because  the  sweep  phase  is  omitted  in  the 
abridged  experiment. 

C.  BOTH  VERSIONS  OF  THE  EXPERIMENT 

Once  all  the  required  choices  have  been  made,  the  controller  may  be  shut  off  and  the 
terminal  should  be  removed.  The  next  time  power  is  applied,  the  controller  will  discover 
that  no  terminal  is  attached,  it  will  consult  the  values  last  stored  in  page  0  to  see  what 
it  should  do,  and  it  will  perform  the  experiment  according  to  those  values. 
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VI.  TESTING  OF  THE  SOFTWARE 

Ever>’  module  of  the  software  has  beert  tested  individually  for  correctness.  The  in¬ 
tegrated  control  program  also  has  been  tested  exhaustively,  but  because  the  hardware 
has  not  yet  been  completely  integrated,  there  is  a  limit  to  what  could  be  accomplished. 
This  chapter  discusses  how  the  testing  has  been  performed  and  suggests  further  tests  to 
be  done  once  hardware  integration  is  complete. 

The  following  hardware  components  have  been  completed  and  have  been  success¬ 
fully  operated  by  the  integrated  software: 

1.  Bubble  memory  for  the  experiment’s  log. 

2.  Terminal. 

3.  Real  Time  Clock. 

4.  On-board  Analog-to-digitai  (A  D)  converter. 

5.  Voltage  Controlled  Oscillator. 

6.  Power  Control  Subsystem. 

In  addition,  a  preliminary  design  of  the  Solid  State  Data  Recorder  (SSDR)  was  tested 
by  Kuebler  [Ref.  9].  His  tests  included  a  demonstration  that  the  olf-board  analog-to- 
digital  converters  associated  with  the  SSDR  functioned  correctly,  that  the  SSDR  prop¬ 
erly  stored  tlie  acoustical  data  provided  to  it  by  the  olf-board  analog-to-digital 
converters,  that  this  data  could  be  retrived  from  the  SSDR.  and  that  an  analysis  could 
then  be  performed  on  the  data.  The  final  version  of  the  SSDR  has  not  yet  been  com¬ 
pleted,  and  in  the  testing  of  the  software  described  in  this  thesis,  no  attempt  has  been 
made  to  emulate  its  performance.  However,  the  controller  dutifully  sends  commands  to 
it  and  makes  repeated  (unsuccessful)  attempts  to  read  its  status  information.  It  also 
notes  its  inability  to  get  correct  responses  in  the  log. 

The  software  has  been  tested  many  times  under  various  conditions,  both  with  and 
wthout  a  terminal  attached.  A  test  requires  the  initialization  of  flags  in  page  0  of  the 
bubble  memory  log  in  advance.  How  to  do  this  is  explained  in  Chapter  V.  HOW  TO 
GET  THE  EXPERIMENT  READY  FOR  A  LAUNCH  on  page  63.  There  are  two 
ways  to  end  a  test,  depending  on  whether  or  not  a  terminal  is  attached. 

I.  If  there  is  a  terminal  attached,  pressing  CTRL  Y  will  interrupt  the  experiment  and 
present  the  highest  level  menu  in  the  diagnostic  subsystem.  The  experiment  can 
be  resumed  by  making  choice 
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Z.  Exit  this  menu. 


To  terminate  the  experiment  completely,  make  choice 
A.  Software  Reset. 

2.  If  there  is  no  terminal  attached,  simply  remove  power  from  the  system.  This  is,  in 
fact,  how  the  experiment  will  be  terminated  at  the  end  of  a  space  flight  (if  the  bat¬ 
teries  last  long  enough.)  Attaching  a  terminal  and  applying  power  will  put  the 
control  program  into  the  diagnostic  subsystem. 

The  results  of  the  experiment  can  be  evaluated  by  making  menu  choice 

I  Examine  or  change  the  data  logged  In  the  bubble  memory. 

The  following  is  a  list  of  the  various  conditions  under  which  the  experiment  has  been 
tested.  The  conditions  are  listed  as  applying  and  not  applying,  where  this  is  meaningful. 
.■\11  these  conditions  resulted  in  satisfactory'  performance  by  the  controller. 

1.  Terminal  present;  terminal  absent. 

2.  Unabridged  experiment  to  be  performed;  abridged  experiment  to  be  performed. 

3.  Sweep  phase  previously  performed;  sweep  phase  not  previously  performed. 

4.  Launch  had  occurred  previously;  launch  had  not  occurred  previously. 

5.  Bubble  memory  space  exhausted  during  test.  The  controller  correctly  ceased  trying 
to  store  more  data  and  continued  to  operate  normally  without  logging  its  actions. 
This  could  not  be  verified  without  the  terminal  attached,  for  with  neither  a  terminal 
nor  a  bubble  memory  log.  the  controller  does  not  generate  enough  outputs  for 
proper  verification  of  its  performance.  There  is  no  reason  to  suppose  that  the  re¬ 
sults  would  be  dilTerent  with  the  terminal  removed,  however. 

6.  Temperature  out  of  limits.  Operation  of  the  bubble  memory  ceased.  Power  was 
applied  to  and  removed  from  the  heater  subsystem  by  commands  to  the  power 
control  subsystem.  These  commands  were  issued  by  the  subprogram  responsible 
for  monitoring  the  heater  s  operation,  namely  moiutor_heaters().  .-Mthough  the 
heater  subsystem  itself  has  not  yet  been  completed,  the  associated  power  relays 
switched  correctly. 

7.  Detection  of  the  Auxiliary  Power  Units  (APUs)  by  the  Matched  Filter  was  and  was 
not  emulated  by  toggle  switch.  The  controller  responded  correctly  in  both  cases. 

8.  Detection  of  launch  by  the  Vibration-activated  Launch  Detector  was  and  was  not 
emulated  by  toggle  switch.  The  controller  responded  correctly  in  both  cases. 

9.  Activation  of  the  Barometric  Pressure  Switches  was  and  was  not  emulated  by  tog¬ 
gle  switch.  In  the  absence  of  activation  of  the  barometric  pressure  switches,  the 
presumption  is  that  launch  did  not  occur.  The  controller  responded  correctly  in 
both  cases. 

10.  Power  was  remosed  abruptly  at  various  points  in  the  procedure  and  then  was  re¬ 
stored.  The  controller  recovered  in  the  desired  manner. 
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After  each  test,  the  contents  of  the  bubble  memor>-  log  were  examined  to  see  what  steps 
in  the  experiment  had  been  performed.  Two  obvious  differences  were  found  between  the 
system’s  behavior  with  and  without  a  terminal  attached.  One  of  these  was  that  with  a 
terminal  attached,  the  diagnostic  messages  issued  during  the  performance  of  the  exper¬ 
iment  were  visible.  The  other  was  that  with  a  terminal  attached,  the  diagnostic  subsys¬ 
tem  did  not  get  control.  No  other  difference  could  be  found  between  system  behavior 
with  and  without  a  terminal  attached. 

There  is  every  reason  to  believe  that  the  control  program  will  work,  as  well  in  the 
Space  Shuttle  as  it  has  in  the  lab.  The  same  tests  should  be  performed  again  once  the 
hardware  is  completely  integrated.  The  only  tests  which  have  not  already  been  done  are 
those  associated  with  the  operation  of  the  Solid  State  Data  Recorder  (SSDR).  The 
interface  with  this  device  is  veiy  simple.  The  controller  sends  commands  and  reads  sta¬ 
tus  information.  The  SSDR  is  otherwise  completely  independent  of  the  controller.  We 
have  already  ascertained  that  the  application  of  power  to  the  SSDR  through  the  power 
control  subsystem  is  done  correctly.  We  have  also  verified  correct  response  to  a  failure 
oi  the  SSDR  to  perform  as  expected.  The  only  thing  we  have  not  tested  is  the  response 
of  th'  control  program  to  correct  responses  from  the  SSDR.  Since  the  response  amounts 
to  making  a  note  of  the  correct  response  in  the  bubble  memorx'  log,  we  do  not  anticipate 
any  difficulty  in  this  area.  The  ability  of  the  controller  to  send  commands  to  the  SSDR 
has  been  tested,  although  the  response  of  the  SSDR  to  these  commands  cannot  be 
evaluated  until  the  final  version  of  the  SSDR  is  complete. 

The  means  of  extraction  of  data  from  the  bubble  memory  log  are  not  veiy  elaborate 
at  this  point.  Data  can  be  extracted  for  two  experiment  steps  at  one  time  by  providing 
the  number  of  the  page  in  the  bubble  memory  log  whose  contents  are  required.  No  ca¬ 
pability  has  been  provided  for  rapid  extraction  of  all  data  to.  say.  a  microcomputer.  This 
does  not  pose  a  serious  problem,  but  data  extraction  would  be  facilitated  by  providing 
subroutines  to  do  it  quickly. 
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VII.  CONCLUSIONS 


The  Vibro-acoustic  Experiment  was  the  first  experiment  produced  at  the  Naval 
Postgraduate  School  for  inclusion  in  a  Space  Shuttle  mission.  In  view  of  the  consider¬ 
able  technical  hurdles  it  presented,  it  is  fair  to  say  it  has  been  a  very  ambitious  project. 
It  has  included  many  disciplines,  such  as  mechanical  engineering,  thermal  engineering, 
digital  electronics,  analog  electronics,  acoustics,  bubble  memoty  technology,  auton¬ 
omous  computer  control,  software  development,  a  matched  filter  for  detecting  an  im¬ 
pending  space  shuttle  launch,  power  control,  and  computer-aided  design  and 
manufacturing  (CAD,  CAM). 

This  thesis  has  concerned  itself  with  overall  control  of  the  experiment  and  with  a 
description  of  one  subsystem,  the  matched  filter.  It  was  not  possible  to  do  this  without 
considering  the  experiment  as  a  whole.  From  the  author's  personal  standpoint,  this  has 
been  very  gratifying.  We  have  used  a  high-level  programming  language  to  do  the  bulk 
of  the  programming  of  a  microprocessor-based  controller,  thus  avoiding  the  labor- 
intensive  burden  of  assembly  language  coding  in  most  areas  of  the  program.  We  have 
efiectively  integrated  this  code  with  the  little  assembly  code  required.  We  have  written 
drivers  for  assorted  hardware  devices,  such  as  a  terntinal,  a  bubble  memoiy  module  and 
a  real-time  clock,  thus  demonstrating  the  close  association  between  hardware  and  the 
software  which  makes  that  hardware  more  than  a  glorified  paper-weight.  We  have  used 
structured  programming  techniques  throughout,  thus  aiding  the  design  process,  as  well 
as  the  understanding  of  the  documentation  represented  in  part  by  this  thesis.  We  have 
created  a  conveniently-used  software  development  system,  making  it  straightfonvard  to 
edit  the  source  files,  compile  or  assemble  them,  link  the  object  modules,  list  source  files 
on  a  printer,  and  place  the  executable  file  in  EPROM. 

This  work  may  benefit  others  who  would  like  to  implement  other  applications.  We 
have  made  it  possible  for  them  quickly  to  get  a  device  controller  programmed  and  op¬ 
erating,  since  so  many  standard  controller  functions  already  exist.  The  C  programming 
language  is  highly  portable,  so  much  of  this  work  would  apply  even  with  a  new  hardware 
design,  ng,  say,  a  faster  microprocessor  with  more  memory. 

Two  other  projects  have  already  benefitted  from  the  work  done  here.  In  one,  the 
experimenters  plan  to  obtain  voltage  versus  current  for  solar  cells  in  space.  In  less  than 
two  months,  the  complete  control  program  for  that  new  application  was  designed  and 


68 


tested  using  the  same  controller  and  much  of  the  software  we  have  described  in  this 
thesis. 

In  another  project  now  underway,  the  author  is  involved  in  the  experimental  evalu¬ 
ation  of  a  thermo-acoustic  refrigerator  in  space.  The  details  of  the  experimental  proce¬ 
dure  in  both  these  cases  differ,  but  the  overall  fundamentals  of  control  of  an  experiment 
are  the  same.  Consequently,  much  of  the  software  described  in  this  thesis  can  be  used 
without  any  modification. 

For  anyone  who  wants  to  build  a  controller  with  modest  requirements  for  speed  and 
ICAM,  the  controller  we  have  used  in  the  Vfibro-acoustic  Experiment  would  be  suitable. 
By  using  the  work  described  in  this  thesis,  one  can  avoid  the  unpleasant  burden  of 
starting  from  scratch.  The  bubble  memory  module  provides  a  further  500K  bytes  of 
random  access,  non-volatile  memor}’  for  whatever  purpose  might  be  required. 

Work  remaining  to  be  done  is; 

1.  Design,  build  and  test  an  improved  controller  which  would  operate  with  more 
memory  and  greater  speed. 

2.  Convert  the  existing  software  to  run  on  the  new  controller.  This  would  entail  re¬ 
placing  the  start-up  code  and  other  machine-dependent  assembly  code,  and  re¬ 
compiling  the  C  language  source  code  using  a  compiler  which  would  generate 
machine-language  code  for  the  new  target  machine.  Software  Development  Sys¬ 
tems.  Inc.,  makes  C  language  cross-compilers  which  would  allow  most  of  the  ex¬ 
isting  set-up  to  be  preserved  intact. 

3.  Modify  the  existing  bubble  memory  drivers  to  permit  storage  of  files.  .\t  the  mo¬ 
ment,  the  bubble  memorx'  is  regarded  as  a  linear  list  of  64-byte  chunks  of  memory. 
Greater  usefulness  would  result  from  the  provision  of  a  file  subsystem. 

4.  Produce  a  manual  for  other  potential  users  of  the  soltware  and  hardware  that 
would  make  it  easy  to  get  new  applications  up  and  running  quickly.  This  could  be 
supplemented  by  improved  routines  to  facilitate  the  generation  of  executable  code. 
At  the  moment,  these  routines  are  specific  to  the  Vibro-acoustic  Experiment  in  that 
they  always  look  in  the  subdirectory-  \vibro\contrIr  for  the  files  they  need.  In  gen¬ 
eral,  they  should  permit  any  subdirectory  to  be  used  to  hold  the  files.  The  exper¬ 
iment  to  evaluate  solar  cell  performance  used  a  series  of  files  and  subdirectories 
whose  structure  exactly  mimicked  the  set-up  described  in  this  thesis,  but  no  rou¬ 
tines  have  been  w'ritten  to  set  these  files  up  automatically. 

5.  Develop  or  acquire  a  softw'are  maintenance  system.  Such  a  system  w'ould  provide 
better  management  of  successive  versions  of  the  control  program.  It  would  also 
include  a  data  dictionary  to  provide  a  definition  of  all  variables  and  functions, 
along  with  a  complete  cross-reference  showing  every  place  these  objects  were  used. 
What  would  the  data  dictionary  gain  us?  It  often  happens  that  in  the  course  of 
making  changes,  we  inadvertently  affect  other  parts  of  a  system.  The  data  dic¬ 
tionary  w  ould  make  it  possible  to  find  all  those  places  and  take  appropriate  action. 
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Microprocessors  have  now  been  in  use  for  just  a  little  over  15  years.  The  use  of 
compiled  programs  to  operate  them  is  an  even  more  recent  development,  since  compiled 
programs  generally  take  up  more  memory  space  than  assembled  programs,  and  abun¬ 
dant  memory  at  low  prices  is  available.  There  are  two  distinct  advantages  to  using  a 
compiler: 

1.  The  code  is  easier  both  to  write  and  to  understand.  This  makes  it  easier  to  get 
applications  running,  and  to  modify  them  later,  even  if  team  members  change  over 
a  period  of  time. 

2.  The  code  is  much  faster  to  create.  This  often  makes  the  difference  between  success 
and  failure,  since  time  can  be  critical,  particularly  in  an  educational  environment. 

Often  these  advantages  outweigh  the  disadvantages: 

1.  The  code  tends  to  take  more  memory'. 

2.  The  code  tends  to  execute  more  slowly. 

In  the  case  of  the  Vibro-acoustic  Experiment,  these  factors  were  of  no  great  conse¬ 
quence,  except  as  already  noted  in  conjunction  with  the  bubble  memory  module.  We 
were  forced  to  use  assembly  code  to  operate  the  bubble  memory  in  order  to  keep  up  with 
the  data  transfer  rate  demanded  by  it.  Had  there  been  an  adequate  bulTer  in  that  hard¬ 
ware,  this  extra  effort  could  have  been  avoided. 

In  fact,  this  last  point  makes  it  clear  that  good  hardware  design  can  greatly  reduce 
the  effort  (i.e.,  the  costs)  associated  with  software  development.  It  is  hard  to  believe  that 
the  job  of  implementing  a  64-byte  buffer  in  hardware  would  be  much  more  difficult  than 
that  of  implementing  a  40-byte  buffer.  Had  Intel  done  this,  we  would  have  been  spared 
months  of  development  difficulties,  during  which  we  did  not  understand  the  reason  why 
the  C  code  did  not  work. 

Finally,  the  use  of  a  compiled  language  which  is  highly  portable  (in  particular  a 
compiled  language  such  as  C)  can  help  protect  the  investment  of  time  and  money  in 
software  which  is  otherwise  threatened  as  obsolete  ha-dware  is  replaced  by  improved 
hardw’are.  In  the  software  industry,  endless  conversions  from  one  hardware  system  to 
a  new  one  seem  to  be  a  permanent  nuisance.  The  ability  to  take  old  programs  and  make 
them  work  on  new  hardware  simply  by  recompiling  them  is  attractive. 

Another  potentially  useful  step  w'ould  be  to  implement  the  controller  software  using 
Ada,  the  Department  of  Defense  compiled  language  now  mandated  for  embedded  soft¬ 
ware  in  all  purchased  systems.  This  would  have  the  advantage  that  Ada  programmers 
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are  likely  to  become  more  and  more  numerous  over  time.  This  would  help  keep  the  work 
already  done  both  current  and  useful. 


71 


APPENDIX  A.  DERIVATION  OF  DESIGN  EQUATIONS  FOR  THE 

MATCHED  FILTER 

This  appendix  presents  derivations  and  proofs  of  results  used  elsewhere  in  this  thesis. 

A.  BIQUADRATIC  FILTERS  USING  TWO  OPERATIONAL  AMPLIFIERS 

Figure  7  on  page  27  shows  the  topology  of  a  generalized  biquadratic  filter  using  two 
operational  amplifiers.  This  topology  is  taken  from  Michael  [Ref  15].  In  this  figure,  Y 
denotes  an  admittance  (the  reciprocal  of  an  impedance).  Michael  gives  ideal  transfer 
functions  in  the  s-domain  from  the  node  marked  V,„  to  the  nodes  marked  F,,  Fj.  and 
Fj.  We  will  have  occasion  to  use  the  first  two  of  these.  Since  Michael  does  not  provide 
derivations  for  these  functions,  they  are  provided  below.  Note  that  the  term  “ideal” 
implies  the  use  of  operational  amplifiers  of  infinite  gain.  While  no  such  operational 
amplifiers  in  fact  exist,  there  do  exist  operational  amplifiers  of  verx'  large  gain,  and  the 
approximation  is  practical  in  many  circumstances,  especially  at  the  low  frequencies  used 
in  the  Vibro-acoustic  Experiment  {i.e.,  the  600  Hz  tone  from  the  .Auxiliary  Power  L'niti. 
For  example,  the  open-loop  gain  of  the  LF-444  operational  amplifier  is  more  than 
60  dB  at  a  frequency/  =  600  Hz. 

From  the  Kirkoff  current  law,  and  referring  to  Figure  7  on  page  27,  we  has  e 


^2  =  ^S  +  4 

4  =  4- 4  (50) 

/,  =  -  h-  (57) 

We  can  find  the  currents  /,  through  /,  by  applying  Ohm’s  law. 

/,={F,-F,)F,  (38) 

I2  =  i^i-^s)y2  (59) 

4  =  (40) 

U  =  {V2-V,)Y,  (41) 

/5  =  (»5'»'/v)>’5  (^2) 
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(43) 


4=  f'sn 

h  =  {Vis-V,)Y,  (44) 

4=^3  Kg.  (45) 

By  substituting  these  currents  into  equations  (35)  through  (37),  we  obtain  the  following 
three,  independent  equations. 

{V,  -  V,)Y^  =  (^5  -  V,^)Y,  +  VsY,  (46) 

{Vis- V,)Y,  =  VjY,  +  {V,-  V,)Y,  (47) 

(l’,-f4)>'',  =  (f4-^2)>V  (-^8) 

Collecting  these  terms  yields 

V,iYj+Ys+Y,)=  l\Y,+  \),.Y,  (49) 

f3()4+  >7+  }*)=  13};+  I;,.):  (50) 

r4(y,  +  }3)=r,r, +  1313.  (5i) 

In  an  ideal  operational  amplifier,  the  inputs  have  equal  voltages,  so  we  can  write 
Vi  =  V\  =  Vy  Rewriting  the  equations  with  Fj  in  place  of  and  I',  gives 

^3(^2  +  ^5  +  ^6)  =  ^’1  ^2  +  ^  /,V^5  (-^) 

F3(r4+l7+>8)=r2>4+^rv>'7  (53) 

y3(r,  +  y3)=K,r,  +  r3y3.  (54) 


These  equations  can  be  readily  solved  by  placing  them  in  matrix  form  first. 


'y,+  y,+  y. 

0 

>3' 

'n' 

y,+  Y,-¥Y, 

-y. 

0 

Vi 

= 

Yi 

Y,  +  Y, 

-y^  -ViJ 

V, 

0 

(55) 


Now  interchange  the  positions  of  Vj  and  1 V 
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■  0  y^  +  yj  +  y^ 

-Yi' 

>2' 

'Ys' 

-y4  y4+y7+>8 

0 

= 

Yy 

5^3  Y,  +  Y3 

-^1. 

_  0_ 

Next  we  move  row  3  to  the  top. 

■-  ^3  y,  +  y,  -  y, 

0  Y^+Ys+Y,  -Y2 
-Y^  Y,+  Y,  +  Y,  0 


— 1 

_ 1 

1 

0 

—1 

Y3 

= 

1^5 

1 - 

- \ 

_ 1 

(56) 


(57) 


Next,  multiply  row  1  by  Y^,  row  3  by  Kj,  and  subtract  the  latter  product  from  the 
former  to  generate  a  new  row  3. 


1 

1 

}',  +  y3 

n  +  J's  +  n 

-  Yi 

'Yi' 

Yi 

=: 

0 

L  0 

-y3(y4+y7+y8)+y4(y,  +  y3) 

Yi 

-n>7 

(58) 


Now  multiply  row  2  by  [  —  y3(y4  +  Y-  4-  Ig)  +  I’i)  )'i  +  I'j)].  row  3  by  ( Ij  +  I',  + 
and  subtract  the  latter  product  from  the  former  to  generate  yet  another  row  3. 


-  >3 
0 
0 


y,  +  Kj 

>•5 
0 


^2  +  >’5  +  y6 


-h 
-  J": 

Yi  +  y’i  +  ^6)  +  yf  -  >^31  >4  +  >'-  +  >s'  +  >4(  >’i  + 


0 

>3 

—  )'3}  -(  >2  +  ^3  +  y^)  ~  ^3^  ~  ^"3(J'4  +  +  ^s)  +  ^4*7  1  +  ^  3*] 


p9) 


From  row  3,  we  can  see  that 


-  y,  Y-(  Y2+Yi+  Y^)  -  KjC  -  r3(  Y^+Y-+  y\)  +  YJ  K,  -t-  K,)] 

-  >'4(  ^'2  +  Fs  +  Ye)  +  Y2Z  -  Y^i  >4  +  ^7  +  yi)  +  >4t  yi  +  >^3)] 


y^y^jy': ^  ^6) -  >''3^3^-  +  y^y*yi  +  y^ysy^  +  yy^yj -  y  >'4V^5 -  y^y^y^ 

^jy  -  y^  l"4(  ys  +  y6)  -  J'i  F: K4  -  Fj Kj K4  -  Kj Kj K,  -  F2  Kj K,  +  y\  Yi  K4  +  >2 Fj F4 


(60) 

(61) 


Many  terms  in  the  numerator  and  in  the  denominator  of  this  expression  add  to  zero, 
so  the  transfer  function  is 


v\  -y3y7(y2  +  y6)+y3ysy8-y,y4}5 

y„.  -  y, };(  y,  +  n)  -  n  >3  y^  -  y^  >3  >  3 


(62) 
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r,(5)  _  y,y,y5+r3>V(y2+};)-r3ys}g 

y\  >;(  >'5  +  n)  +  >2  yn  +  ni  ‘  ^  ^ 

^'(5) 

This  completes  the  derivation  of  ■.  To  derive  the  transfer  function  — --r.  we 

T,v(s)  f'jvfs) 

modify  equation  (55)  by  placing  the  variable  in  the  last  position. 


-5^2 

Y2+Y,+  Y, 

0 

Y,-YY-,+  Y, 

-y, 

y,  +  yg 

=  T, 


-  n 


Proceeding  as  before,  we  multiply  row  3  by  -  Vj  ,  row  1  by  -  }\,  and  subtract  the 
former  product  from  the  latter  to  generate  a  new  row  3. 


1  ^  +  I’s  +  1 6 


0  V 


0  r^+is  +  n  ->4  V,  =  Y,  V;y.  (65) 

_  0  y,(}2+}5+T,)-i2(T,  +  r3)  [t,15_ 

Next  multiply  row  2  by  [ }',(Tj  +  I’j  +  i;)  -  }j(r,  +  Tj)]  ,  row  3  by  (I*  +  Y,  +  I',)  , 
and  subtract  the  latter  product  from  the  former  to  yield  a  new  row  3. 

-  yy  >:  +  J'5  +  0  ‘I 

0  +  V-  +  Pj  —  )\  ly 

0  0  Y2  Yi( n  +  K,  +  Ps)  +  nc  b](  >;  +  Yi  +  Ys)  “  I'l  +  >3)]  ^2 

r  V-  1 

*  5 

=  >  -  l',y. 

.^1^5(P4+  P' +  f's)  —  ^’5+  ^6*  ~ 

From  row  3  we  can  see  that 

V2  r,r5(r4+i7-n^8)-T,r.(r2+K5+y;)-n-,r,(T,  +  T3) 

y,s  Yi  Yii  >4  +  Y,  +  Tg)  +  y,  y,(  Y2  +  Y,  +  Y,}  -  }',  ni  y,  +  1-3)  •  ^ 

As  before,  many  terms  in  both  the  numerator  and  the  denominator  add  to  zero,  so 


Vj  _  Y,  YsiY,  +  Y,)  +  Y^YJ,  -  y,  Y,Yy 
Yl\  ^2  ^7  +  ^s)  ^  1  ^4(^  5  ^6) 
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It  is  possible,  using  the  same  method  illustrated  in  both  these  cases,  to  develop  a 
transfer  function  -rr — We  have  no  use  for  this  particular  function  in  the  present 
context,  however,  so  the  derivation  is  omitted. 

B.  HIGH-PASS  NOTCH  FILTER 

The  equation  of  a  notch  filter  is  given  in  equation  (6),  repeated  here. 


.Michael  [Ref.  15)  shows  how  to  use  the  generalized  configuration  of  Figure  7  on 
page  27  to  implement  this  function  in  the  case  where  a>,  =  a>,,  which  is  the  case  for  a 
symmetric  notch  filter.  However,  he  does  not  show  how  to  implement  an  asymmetrical 
notch  filter,  in  which  a>,. 

We  can  do  so  by  using  equation  (63)  and  making  the  following  choices  for  the 
admittances  F,  through  IV 
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(80) 


C.  LOW-PASS  NOTCH  FILTER 

To  get  a  low-pass  notch  filter,  we  use  equation  (68)  and  pick  admittances  as  follows; 
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Proof 
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s  +  (Or. 


Converting  equations  (86)  and  (87)  to  use  resistances  instead  of  conductances,  we 
get  the  design  equations 


Rb<^p  ' 
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D.  A  SECOND-ORDER,  LOW-PASS  FILTER  USING  ONLY  ONE 
OPERATIONAL  AMPLIFIER 

Figure  14  on  page  36  is  the  schematic  of  a  generalized  second-order,  low-pass  filter. 
The  general  equation  of  a  low-pass  biquadratic  filter  is  given  by  [Ref.  12  :  p.  16]  as 


Vois) 
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^  I si^)  2  . 

5  + 

f  ^p\  ^  2  ■ 

(91) 


This  transfer  function  can  be  realized  by  the  schematic  in  Figure  14  on  page  36  if 
we  make  the  following  choices  for  the  components. 
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From  equation  (94), 
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We  can  manipulate  this  equation  to  obtain  the  transfer  function. 

Ko[sV,C2/?,/?i  +  sC2Ri  +  1  +  sC2/?2]  =  (100) 
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If  we  choose  /?,  =  /?,  =  /?,  then 
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To  design  a  filter  to  provide  desired  values  of  w,  and  Q, ,  use  the  design  equations 
which  can  easily  be  derived  from  the  above  equations. 

1.  Pick  Cj  arbitrarily. 

2.  LetC.  =  4Q0. 

3.  Let /?,  =  /?,  =  /?  = - p=:r. 

cojQC, 
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APPENDIX  B.  CHOICE  OF  A  SOFTWARE  DEVELOPMENT  SYSTEM 


A.  Z-80  ASSEMBLY  LANGUAGE 

The  Vibro-acoustic  Experiment  has  a  fairly  long  history’.  Long  before  the  author 
became  associated  with  the  project,  two  distinct  choices  for  a  software  environment! 5 
had  already  been  made.  Early  in  the  project  we  used  Z-80  assembly  language  for  pro¬ 
gramming  the  controller.  An  ALTOS  eight-bit  microcomputer  running  under  Digital 
Research  Corporation’s  Control  Program  for  Microcomputers  (CP,  .M)  was  available. 
It  included  a  Z-80  assembler  (M80),  a  librarian  (LIB80)  and  a  linker  (L80).  However, 
the  turnover  in  student  personnel  is  rather  high  at  any  educational  institution;  the  Naval 
Postgraduate  School  is  no  exception.  .Assembly  language  is  often  not  the  best  choice  for 
a  project  whose  participants  do  not  remain  for  the  life  of  the  project,  since  assembly 
language  is  not  widely  known,  is  not  easy  to  learn,  and  is  highly  dependent  on  the  ar¬ 
chitecture  of  the  machine  in  which  the  final  program  is  to  operate.  Many  different  ar¬ 
chitectures  exist,  and  most  machines  have  unique  architectures.  Even  those  who  know 
how  to  program  with  assembly  language  often  are  averse  to  expending  the  vast  amounts 
of  time  required  to  use  it  for  any  but  the  most  trivial  programs. 

B.  CP/M  AND  TOOLWORKS  C 

.As  a  consequence  of  these  facts,  one  of  the  early  participants  in  the  project  suc¬ 
cessfully  promoted  a  switch  away  from  Z-80  assembly  language  to  the  C  programming 
language.  This  high-level  language  includes  powerful  operators  which  make  it  easy  to 
manipulate  the  bits  within  the  bytes  of  the  computer’s  memory,  and  so  it  can  do  almost 
anything  that  can  be  done  in  assembly  language.  The  same  ALTOS  CP  M  system 
happened  to  have  Toolwork’s  C  compiler  on  it,  and  so  wx  used  it. 

When  the  author  joined  the  project,  little  progress  had  been  made  in  actually  writing 
the  control  program.  With  Captain  Frank  .Mazur,  US.MC,  and  Captain  Ron  Byrnes, 
USA,  the  author  wrote  much  of  the  control  program  on  the  ALTOS  under  CP,  M  using 
the  Toolwork’s  C  compiler. 

15  The  term  software  environment  refers  to  the  computer,  the  operating  system,  the  program¬ 
ming  language,  and  all  related  software  and  hardware  tools  used  to  program  a  computer.  The 
c  Tiputer  on  which  the  development  of  software  is  done  need  not  necessarily  be  the  same  one  as 
that  in  which  the  completed  program  will  reside  and  be  executed.  In  the  case  of  the  Vibro-acoustic 
E.xperiment,  it  is  not  the  same  computer. 
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Doing  so  proved  to  be  a  frustrating  business.  The  ALTOS  was  equipped  with  two 
eight-inch,  single-sided,  single-density,  floppy  diskette  drives.  These  could  contain  only 
around  250  Kbytes  of  data.  One  drive  had  to  contain  a  copy  of  the  CP  M  operating 
system  at  nearly  all  times.  The  ALTOS  was  quite  slow  by  present  standards;  it  was  not 
uncommon  for  a  compilation  to  take  five  minutes.  Due  to  the  limited  disk  space  avail¬ 
able,  the  output  of  the  compiler  (an  8080  assembly  language  source  filei6  )  had  to  be 
transferred  to  another  diskette  before  assembly  could  proceed.  Assembly  typically  con¬ 
sumed  a  further  five  minutes.  The  libraiy  program  was  quite  inconvenient  to  use,  but 
once  the  e.xecutable  modules  had  been  loaded  successfully  into  a  library,  linking  w'as 
straightforward.  This  was  a  comparatively  quick  two-minute  process. 

Our  EPRO.VI  writing  program  was  on  an  IB.M-PC  using  Microsoft’s  Disk  Operating 
System  (.MS  DOS).  Furthermore,  that  machine  had  only  5  1  4  inch  diskettes.  So  we 
took  our  eight-inch  floppies  to  a  Zenith  Z-100  that  had  both  sizes  of  drives,  where  we 
converted  the  CP  M  file  containing  executable  code  into  an  MS  DOS  file  on  a  5  14  inch 
diskette. 

Finally,  we  loaded  the  executable  program  from  the  diskette  into  the 
EPROM -writing  program  and  created  the  firmware. 

C.  MS/DOS  AND  UNIVVARE  C 

It  should  not  have  taken  us  too  long  to  tire  of  this  agonizing  procedure.  In  fitct,  it 
was  over  a  year  before  we  began  seriously  to  search  for  an  improvement  in  the  form  of 
a  cross-compiler.  We  wanted  a  C-language  compiler  which  would  operate  on  an  IBM 
PC  using  MS  DOS,  and  which  would  generate  Z-SO  object  code.  Several  were  available. 
We  selected  the  LniWare  C  Compiler  package  from  Software  Development  Systems. 
31 10  Woodcreek  Drive,  Downers  Grove,  IL  60515.  This  product  is  a  complete  software 
development  system.  It  includes  a  C  compiler  which  produces  Z-80  assembly  code,  a 
Z-80  assembler,  a  library  manager  to  store  object  modules  in  a  single  MS  DOS  librarv' 
file,  a  linker  to  convert  a  collection  of  object  modules  into  an  executable  file,  and  a  large 
collection  of  utility  programs,  useful  for  listing  files,  converting  files  from  one  format  to 
another,  and  so  on.  The  compiler  implements  the  complete  C  language  defined  by 

16  The  Toolwork’s  C  compiler  generates  8080  assembly  language  source  code.  The  NSC800 
on  the  controller  board  can  execute  Z-80  code,  a  subset  of  the  NSC800  instruction  set,  and  the  8080 
instruction  set.  which  is  itself  a  subset  of  the  Z-80  instruction  set.  We  had  an  assembler  for  Z-80 
and  8080  code.  We  needed  two  Z-80  instructions  not  available  in  the  8080  instruction  set.  So  we 
embedded  Z-80  machine  code  in  the  8080  assembly  source  created  by  the  C  compiler  and  executed 
the  resultant  module  with  an  NSC800.  It  really  was  at  least  as  complicated  as  it  sounds! 
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Kernighan  and  Ritchie  [Ref.  16].  It  also  includes  enhancements  similar,  but  not  identi¬ 
cal,  to  those  proposed  by  the  American  National  Standards  Institute  (.ANSI). 

It  took  a  little  time  to  convert  from  the  old  to  the  new  system,  but  the  results  were 
well  worth  the  effort.  Because  the  performance  of  the  IBM  System  2  Model  SO  on  which 
we  run  this  system  is  so  much  greater  than  that  of  the  Altos,  we  are  able  to  generate  a 
new  version  of  the  controller  program  in  much  less  time.  The  use  of  MS  DOS  also  has 
provided  significant  benefits.  We  have  made  extensive  use  of  hierarchical  file  directories 
in  order  to  group  files  in  a  logical  manner.  We  also  use  MS  DOS  batch  files  to  minimize 
the  amount  of  memorj'  work  necessary  to  execute  such  programs  as  the  compiler  and 
the  linker. 

The  documentation  supplied  with  the  UniWare  system  [Ref  17]  is  excellent.  Unlike 
most  C  compilers,  this  one  is  not  meant  to  produce  executable  code  running  under  an 
operating  system.  For  this  reason,  much  of  the  standard  library  supplied  with  other  C 
compilers  is  not  applicable,  and  is  not  supplied.  In  particular,  no  libraiy  functions  are 
provided  to  perform  disk  input  or  output.  However,  common  output  formatting  rou¬ 
tines  such  as  printfO  are  included. 

D.  GENERATION  OF  FIRMWARE  IN  EPROM 

We  use  the  Intel  program  pepp  to  load  the  completely  linked  program  into  EPROM. 
The  UniWare  software  can  create  a  symbol  table  showing  what  should  go  where.  .Armed 
with  this  list,  one  can  load,  install,  and  test  the  new  version  of  the  program  in  short  or¬ 
der. 

Details  on  the  operation  of  this  program  are  presented  in  Section  2.  Getting  the 
Executable  Program  into  EPRO.M  on  page  146. 


85 


APPENDIX  C.  HOW  THE  UNIVVARE  SOFTWARE  USES  THE 

COMPUTER  MEMORY 


The  UniVVare  software  regards  memory  as  comprised  of  a  number  of  named  regions. 
The  C  compiler  itself  creates  five  of  these  [Ref.  17;  Compiler  section,  p.3].  These  are  the 
regions  code,  string,  const,  data,  and  ram.  There  are  three  further  software  regions: 
reset,  mbrkram,  and  stack.  The  purpose  of  each  region  is  described  below.  The  linker 
treats  each  region  as  a  unit  and  places  its  contents  in  memory  in  contiguous  storage  lo¬ 
cations.  It  decides  how  to  do  this  based  on  instructions  in  the  file 
\vibro\contrlr\object\spec.  The  order  in  which  these  regions  appear  in  memoiy  is  speci¬ 
fied  in  this  file,  and  reflected  both  in  Figure  19  on  page  44,  and  in  the  order  in  which 
they  are  described  here. 

reset  The  Z-SO  architecture  specifies  that  the  program  code  stored  at  memory 
location  0\0000  be  executed  whenever  the  microprocessor  receives  power 
or  a  hardware  reset  occurs.  The  reset  region  contains  an  appropriate 
start-up  program.  This  program  does  the  following: 

1.  It  initializes  the  stack  pointer  to  0x0000.  Whenever  an  item  is  stored  in 
the  stack,  the  stack  pointer  is  first  decremented.  Thus,  the  stack  pointer 
will  initially  be  decremented  to  OxflTl'.  the  first  location  in  the  stack,  and 
will  continue  to  grow  downward  in  memory  from  this  point. 

2.  It  initializes  the  interrupt  tables  in  such  a  manner  that,  should  a  spurious 
interrupt  occur,  the  control  program  will  restart  from  the  beginning.  It 
would  be  preferable  to  resume  e.xecution  by  simply  returning  from  the 
interrupt.  This  would  raise  the  unacceptable  possibility,  however,  of  an 
indefinite  suspension  of  the  execution  of  the  program  if  some  unpredict¬ 
able  cause  led  to  the  problem.  While  restarting  has  the  disadvantage  of 
totally  disrupting  matters,  its  compelling  advantage  is  that  e.xecution  re¬ 
sumes  from  a  known  state,  barring  a  complete  catastrophe. 

code  This  region  contains  all  program  instructions  generated  by  C  and  assembly 
language  source  code.  It  includes  code  to  do  the  following  things: 

1.  Program  variables  must  be  in  RA.M  to  be  altered.  In  the  C  program¬ 
ming  language  it  is  possible  to  assign  initial  values  to  these  variables  at 
the  time  a  program  is  compiled.  These  values  must  be  placed  in 
EPRO.M,  since  otherwise  they  would  be  lost.  One  of  the  routines  in  the 
code  region  is  invoked  at  start-up  time  to  copy  initialized  variables  from 
their  permanent  locations  in  region  data  in  EPROM  into  temporan.’  lo¬ 
cations  in  R,-\M.  Thus  in  Figure  19  on  page  44  region  data  appears  in 
two  locations,  both  in  EPRO.M  and  in  lUAM, 
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2.  The  definition  of  the  C  prograntnting  language  specifies  that  static^  and 
externalis  variables  which  have  no  initial  value  specified  in  their  decla¬ 
rations  must  be  initialized  by  the  compiler  to  the  value  0  [Ref  16:  p.l98]. 
One  of  the  routines  in  the  code  region  is  invoked  at  start-up  time  to  put 
zeros  in  all  RAM  locations  in  region  ram. 

3.  Another  routine  which  is  invoked  at  start-up  time  calls  the  C  program 
main().  This  is  the  highest  level  program  in  C.  It  calls  subordinate 
routines  to  operate  the  controller  and  run  the  experiment  itself. 

string  Whenever  the  compiler  finds  a  quoted  character  string  in  the  source  code, 
it  places  it  in  the  string  region.  Since  strings  are  treated  as  constants,  they 
can  be  kept  in  EPRO.M.19 

const  Variables  declared  as  const  are  regarded  by  the  compiler  as  invariant,  or 
constant,  so  it  is  reasonable  to  place  them  in  EPROM. 

data  This  region  contains  variables  whose  initial  values  were  specified  at  the  time 
of  compilation.  These  values  are  placed  in  EPRO.M  by  the  linker  so  that 
they  will  not  he  lost  when  power  is  removed  from  the  controller.  However, 
variables  must  be  in  R.AM  when  the  program  executes.  During  the  start-up 
procedure,  they  are  copied  into  R.AM. 

ram  This  region  contains  variables  whose  initial  values  were  not  specified  at  the 
time  of  compilation.  These  are  initialized  to  0  at  the  time  the  program  is 
first  invoked,  as  specified  in  Kernighan  and  Ritchie  [Ref  16  :  p.  198]. 

mbrkram  The  UniWare  C  compiler  provides  a  function  mbrk()  to  permit  a  program 
to  request  storage  at  run  time  {i.e..  dynamically).  The  mbrkram  region 
provides  mbrk()  with  the  storage  it  needs. 

stack  The  program  stack  is  located  here,  at  the  top  of  memory. 

The  linker  ensures  that  items  within  a  region  are  stored  contiguously.  The  compiler 
decides  where  to  put  these  partitions  in  memory  by  examining  a  memory  map  provided 
in  the  specification  file  \vibro\contrlr\object\spec,  listed  in  Section  A.  Filename  spec  on 
page  150.  The  format  of  this  file  is  described  in  [Ref  17:  Link  Editor  Section,  p.  7|. 

The  memory  map  specifies  that  reset  be  loaded  at  address  OxUOOO,  that  the  stack 
grow  down  in  memory  from  address  OxfflT,  that  EPRO.M  is  available  from  addresses 
0x0000  through  OxSflT,  and  that  RAM  is  available  starting  from  address  OxeOOO  through 
Oxfiir. 


1 7  Static  variables  retain  their  values  even  after  the  program  which  declared  them  finishes  ex¬ 
ecuting. 

18  External  variables  are  declared  in  some  module  other  than  the  one  in  which  a  program  using 
these  variables  is  defined. 

19  In  general,  to  modify  strings  a  programmer  must  first  place  a  copy  of  them  into  a  variable. 
Dynamic  variables  are  always  located  in  RAM,  since  their  contents  are  changeable. 
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APPENDIX  D.  HIERARCHICAL  ORGANIZATION  OF  SOFTWARE 

FILES 

All  the  software  to  control  the  Vibro-Acoustic  Experiment  is  located  in  the  file  hi¬ 
erarchy  illustrated  in  Figure  35  on  page  89.  Following  is  a  description  of  the  contents 
of  each  of  these  subdirectories. 

A.  SUBDIRECTORY  \VIBRO\CONTRLR\HEADERS 

This  subdirectory  contains  header  files  for  the  C  language  source  code.  The  header 
files  allow  numeric  constants  which  are  used  in  creating  the  program  to  be  specified 
symbolically.  By  avoiding  the  use  of  “magic”  numbers  in  the  source  code,  the  code  is 
rendered  much  more  readily  understood.  The  header  files  also  contain  external  declara¬ 
tions  of  the  functions  and  variables  contained  within  a  module.  Whenever  one  module 
needs  to  use  the  functions  or  variables  of  a  different  module,  it  can  obtain  correct  dec¬ 
larations  of  them  by  including  the  appropriate  header  file  using  the  C  programming 
language  #include  directive. 

B.  SUBDIRECTORY  \VIBRO\CONTRLR\CSOURCE 

This  subdirectory  contains  C  language  source  code  for  the  parts  of  the  controller 
program  written  in  the  C  programming  language. 20 

C.  SUBDIRECTORY  \VIBRO\CONTRLR\ASMSOURC 

This  subdirectory  contains  Z-80  assembly  language  source  code.  A  few  of  the  lowest 
level  routines  in  the  controller  software  have  been  written  in  assembly  language,  but  only 
when  there  was  no  apparent  way  to  write  them  in  C  (e.g.,input(),  outputO),  or  when  the 
C  compiler  couldn’t  generate  code  which  would  execute  rapidly  enough  (e.g.,  bubreadQ 
and  bubnriteO). 

D.  SUBDIRECTORY  \VIBRO\CONTRLR\BATCH 

This  subdirectory  contains  a  number  of  MS, 'DOS  “batch”  files.  These  contain  se¬ 
quences  of  commands  which  make  it  easier  to  compile  programs,  print  listings  of  the 
source  code,  link  object  modules,  and  load  executable  modules  into  EPROMs. 

20  This  comprises  most  of  the  controller  software. 
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Figure  35.  Hierarchical  Organization  of  Softnaie  Files:  1  lie  software  files  are 
grouped  into  several  different  sub-directories  to  facilitate  finding  and 
managing  them. 


E.  SUBDIRECTORY  \VIBRO\CONTRLR\LIST 

I  his  subdirectory  contains  output  listings  produced  either  by  the  C  compiler  or  by 
the  Z-80  assembler. 21  I  hose  created  from  C  source  code  include  that  code  in  the  form 
of  comments  to  the  Z-80  assembler.  They  are  stored  in  this  subdirectory  only  as  a 
matter  of  convenience,  in  order  that  they  not  clutter  up  the  directory  listing  of  the  sub¬ 
directories  containing  the  source  code. 

F.  SUBDIRECTORY  \VIBRO\CONTRLR\OBJECT 

This  subdirectory  contains  object  modules  produced  either  by  the  C  compiler  or  by 
the  Z-80  assembler.  They  arc  stored  in  this  subdirectory  only  as  a  matter  of  conven¬ 
ience,  in  order  that  they  not  clutter  up  the  subdirectories  containing  the  source  code. 


21  Those  produced  by  the  C  compiler  are  actually  assembly  language  listings  produced  by  the 
Z-80  assembler.  I  he  latter  is  called  by  the  C  compiler. 
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This  subdirectorj'  also  contains  the  link  specification  file  spec.  This  file  provides  the 
linker  with  information  needed  to  decide  where  the  various  regions  of  the  program  must 
be  loaded.  A  number  of  global  variables  are  set  by  this  file  at  link  time. 

For  details  on  how  to  use  a  link  specification  file,  see  the  discussion  in 
[Ref.  17:  Link  Editor  Section,  p.  7]. 
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APPENDIX  E.  SUBROUTINES,  IN  ALPHABETICAL  ORDER  BY  NAME 

Table  8.  SUBROUTINE  INDEX:  This  table  shows  the  names  of  the  MS,  DOS 


files  in  which  each  subroutine  can  be  found.  Subroutines  are  listed  al- 
phabetically  by  name. _ 


SUBROUTINE 

SOURCE 

FILE 

PURPOSE 

ad_read() 

expmnt.c 

Gets  a  character  of  data  from  the  Analog- 
to-digital  (A  D)  Converter. 

adtointO 

expmnt.c 

Converts  a  character  of  raw  data  from  the 
Analog-to-digital  {A  D)  Converter  into  an 
integer  format  with  the  more  meaningful 
units  of  volts  or  degrees  kelvin. 

alter_pageO() 

expmnt.c 

Permits  the  user  to  alter  the  contents  of  page 

0  of  the  bubble  memoiy.  This  is  required  in 
initializing  the  experiment. 

allo»_ctrl_interrupts() 

inout.c 

Processes  the  special  characters  CTRL  S  and 
CTRL  Y  when  read  from  the  keyboard. 

CTRL  S  is  a  toggle  switch.  The  first  time  it 
is  pressed,  the  display  halts.  The  second  time 
it  is  pressed,  the  display  resumes.  Subse¬ 
quently  its  function  alternates  between  these 
two.  CTRL  Y  invokes  the  diagnostic  sub¬ 
system. 

atoh() 

convert.c 

Converts  an  ASCII  string  representation  of 
a  hexadecimal  byte  into  the  corresponding 
hexadecimal  byte.  For  example,  the  string 
“a3’‘  is  converted  to  the  byte  value  0xa3. 

atohexintO 

convert.c 

Converts  a  four-byte  .ASCII  string  repres¬ 
enting  a  two-byte  hexadecimal  word  into  the 
corresponding  hexadecimal  word.  For  ex¬ 
ample,  the  string  “a34b”  is  converted  to  the 
word  0xa34b. 

atoiO 

convert.c 

Converts  a  string  representing  a  decimal  in¬ 
teger  into  the  corresponding  integer.  This 
subroutine  is  from  Bilofsky  [Ref  1 8). 

badjdea_to_record0 

expinnt.c 

This  routine  is  used  in  the  abridged  exper¬ 
iment  to  prevent  record  mode  from  being  re¬ 
started  after  a  power  fault.  Without  this 
safeguard,  perfectly  good  data  recorded  dur¬ 
ing  launch  nught  be  erased. 
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baro_switch() 

expmnt.c 

Checks  to  see  if  the  barometric  switches  have 
been  activated  yet.  If  so,  launch  must  have 
occurred  and  an  appropriate  log  entry  is 
made. 

bcd_ascO 

coQvert.c 

Converts  a  BCD  b>'te  to  the  corresponding 
character  string  representation.  For  exam¬ 
ple,  0x17  is  converted  to  “17". 

bcd_int() 

convert.c 

Converts  a  one-byte  BCD  number  to  integer 
format. 

bpagesetO 

bubbie.c 

Loads  the  five  parametric  registers  in  the 
bubble  memory  controller.  Most  of  these 
never  change.  Two,  however,  do  change  of¬ 
ten.  These  two  specify  the  page  of  bubble 
memory  where  transfers  of  data  begin.  Call 
this  function  prior  to  any  operation  per¬ 
forming  input  from  or  output  to  the  bubble 
memory  to  ensure  the  parameters  are  cor¬ 
rectly  specified. 

bubcmdnienuO 

bubble.c 

Displays  a  menu  of  low-level  bubble  memory 
controller  commands.  These  are  useful  in 
testing  the  bubble  memory  for  proper  oper¬ 
ation. 

bubinitO 

bubbie.c 

Initializes  the  bubble  memory  prior  to  its 
being  used.  This  initialization  must  always 
be  done  after  power  is  applied  and  before 
input  and  output  operations  begin. 

bubioO 

bubble.c 

Performs  input  from  and  output  to  the  bub¬ 
ble  memory. 

bubmenuO 

bubbie.c 

Provides  a  menu  of  functions  permitting  the 
user  to  perform  operations  with  the  bubble 
memory.  These  operations  include: 

1.  applying  and  removing  power, 

2.  initialization, 

3.  input, 

4.  output  and 

5.  reading 

the  status  of  the  bubble  memory\ 

bub_off() 

bubble.c 

Removes  power  from  the  bubble  memory. 

bub_on() 

bubble.c 

Applies  power  to  the  bubble  memory. 

bubreadQ 

bubnv.s 

Takes  care  of  the  actual  transfer  of  data  from 
the  bubble  memory’  to  the  controller  memory- 
during  a  read.  This  routine  was  written  in 
assembly  language  in  order  to  achieve  a  data 
transfer  rate  of  16  K  bytes  per  second  im¬ 
posed  by  the  bubble  memory  hardware. 

bubwriteO 

bubnv.s 

Takes  care  of  the  actual  transfer  of  data  to 
the  bubble  memory  from  the  controller 
memory  during  a  write.  This  routine  was 
wTitten  in  assembly  language  in  order  to 
achieve  a  data  transfer  rate  of  16  K  bytes  per 
second  imposed  by  the  bubble  memory- 
hardware. 

bubxferO 

bubnv.s 

Part  of  the  sequence  of  steps  necessary  to 
initialize  the  bubble  memory  entails  trans¬ 
ferring  the  byte  OxfT  to  the  bubble  memory- 
40  times.  This  routine  does  this.  The  rou¬ 
tine  is  written  in  assembly  language  for 
speed,  but  is  called  in  the  same  manner  as  a 

C  routine. 

checkprtO 

expmnt.c 

Checks  to  see  whether  or  not  there  is  a  ter¬ 
minal  connected  to  the  RS-232C  serial  inter¬ 
face  port. 

clockintQ 

cIock.c 

Dates  and  times  in  the  real  time  clock  are 
stored  in  BCD  format.  This  routine  converts 
them  to  integer  format  to  make  it  convenient 
to  perform  arithmetic  with  them.  Thus,  fu¬ 
ture  dates  and  times  can  be  computed. 

clockreadO 

clock.c 

Reads  the  current  date  and  time  from  the 
real  time  clock. 

clockcompareO 

clock.c 

Compares  two  clock  times  to  see  which  one 
is  later  than  the  other. 

clocksetO 

clock.c 

Sets  the  current  date  and  time  in  the  real 
time  clock  according  to  values  specified  by 
the  user. 

clocksumO 

clock.c 

Adds  two  dates  and  times  together  to 
produce  a  new  date  and  time.  In  practice, 
one  uses  this  to  calculate  a  future  date  and 
time  from  the  current  date  and  time  and 
some  desired  delay  {e.g.,  15  minutes). 

coIder.thanQ 

expmnt.c 

Returns  the  value  TRUE  if  the  bubble 
memory’s  temperature  is  below-  the  temper¬ 
ature  given  in  the  argument  to  the  function, 
FALSE  otherwise. 

ctoh() 

convert.c 

Converts  a  single  character  to  its 
hexadecimal  ASCII  string  representation. 

For  example,  0xa3  is  converted  to  “a3". 
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delayO 

delay.s 

Provides  a  software-driven  time  delay  in  in¬ 
crements  of  10  ms.  Written  in  assembly 
language,  but  used  like  a  C  language  routine. 
Adapted  from  a  program  by  Mr.  David 
Rigmaiden  of  the  Naval  Postgraduate 

School. 

display_j)ageO() 

expmnt.c 

Displays  the  contents  of  page  0  in  a  readable 
format. 

display_data_page() 

expmnt.c 

Displays  the  contents  of  any  page  in  the 
bubble  memory  in  a  readable  format.  It  will 
not  successfully  display  page  0.  Use 
display  jiageOO  for  this  purpose. 

do_sweepO 

expmnt.c 

Causes  the  sweep  phase  of  the  experiment  to 
be  performed. 

dump() 

inout.c 

Produces  a  he.xadecimal  and  ASCII  dump 
of  any  desired  region  of  memory. 

dunip_clock() 

clock.c 

Display  the  date  and  time  on  the  terminal. 

dump_iclockO 

clock.c 

Display  the  date  and  time  on  the  terminal. 

This  differs  from  dump_clock()  in  that  the 
dates  and  times  it  uses  are  integers,  not  Bi¬ 
nary  Coded  Decimal  (BCDl  numbers. 

echoO 

inout.c 

Sends  a  single  character  to  the  terminal. 

expmntO 

expmnt.c 

Causes  the  Vibro-acoustic  Experiment  to  be 
performed. 

fputc() 

fputc.c 

The  UNIW.ARE  compiler  provides  the 
standard  C  output  routine  printf()  to  provide 
output  to  the  standard  output  device.  How¬ 
ever.  this  routine  requires  the  user  to  provide 
a  routine  fputc()  to  handle  the  output  of  a 
single  character  to  any  arbitrary  device.  We 
only  support  output  by  fputc()  to  the 

RS-232C  terminal,  so  this  routine  is  specific 
to  that  device.  The  routine  will  noi  output 
a  character  if,  upon  checking,  it  finds  there 
is  no  terminal  attached  to  the  serial  interface 
port.  Thus,  when  the  experiment  is  operat¬ 
ing,  calls  to  printfQ  are  of  no  effect  unless 
there  is  a  terminal  connected. 

getbexQ 

inout.c 

Inputs  a  string  representation  of  a  two-digit 
hexadecimal  number  from  the  terminal  and 
converts  it  to  hexadecimal  format.  For  ex¬ 
ample,  “3a”  is  converted  to  0x3a. 

gethexintO 

inout.c 

Gets  a  four-digit  hexadecimal  number  in 
string  format  from  the  terminal  and  converts 
it  to  a  hexadecimal  word.  For  example, 
“3ab2”  is  converted  to  Ox3ab2. 

94 


getintO 

inout.c 

Inputs  a  string  representation  of  a  decimal 
integer  from  the  terminal  and  converts  it  to 
integer  format.  For  example,  “352’’  is  con¬ 
verted  to  352. 

getpagenoO 

inout.c 

Asks  the  user  for  a  page  number  in  bubble 
memory. 

get_tiine() 

clock.c 

Obtain  a  valid  date  and  time  from  the  user. 

inithardwareO 

initial.c 

Initializes  the  six  ports  on  NSC810A  and 
#?2. 

input() 

nenio.s 

Inputs  a  character  from  a  port.  Written  in 
assembly  language,  but  used  like  a  C  lan¬ 
guage  routine. 

int_bcd() 

convert.c 

Converts  an  integer  in  the  range  0  through 

99  to  BCD  format. 

issububcmdO 

bubble.c 

Issues  commands  to  the  bubble  memory 
controller  and  analyzes  the  status  codes 
which  result.  In  many  cases,  it  will  attempt 
to  issue  a  command  repeatedly  if  there  is 
some  failure,  doing  this  up  to  a  specified 
number  of  times.  This  routine  is  written  in 

C  and  is  not  fast  enough  to  handle  the  read 
and  write  commands.  Use  bubread()  and 
buburitei )  for  these. 

itoa() 

convert.c 

Converts  an  integer  to  an  ASCII  string  rep¬ 
resentation.  This  subroutine  is  from  Bilofskv 
[Ref  1S|. 

listenO 

expmnt.c 

Listens  for  the  Au.xiliary  Power  Units 
(.•\PUs)  to  be  activated.  It  also  monitors  the 
Vibration-activated  Launch  Detector  and 
the  Barometric  Pressure  Switches  to  see  if  a 
launch  has  occurred  without  detection  of  the 
activation  of  the  .APUs. 

logeventO 

expmnt.c 

Makes  entries  into  the  event  log  stored  in  the 
bubble  memor>’. 

log_menu() 

expmnt.c 

Displays  a  menu  to  provide  for  conveniently 
changing  the  contents  of  bubble  memory. 

This  is  essential  for  properly  initiating  the 
experiment. 

Iook_aheadO 

inout.c 

This  program  can  see  whether  a  character 
has  been  input  from  the  keyboard  without 
disturbing  the  input  buffer. 

mainQ 

main.c 

First  C  language  subroutine  to  get  control 
after  start-up.  Decides  whether  to  invoke 
the  menu-driven  diagnostic  routines  or  to 
run  the  Vibro-acoustic  Experiment. 
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mbrkO 

mbrk.s 

Implements  the  C  language  standard  librar\- 
function  mbrk().  This  function  was  provided 
with  the  L'niware  C  Compiler. 

meinory_dumpO 

main.c 

Asks  the  user  for  an  address  in  memory  and 
the  number  of  bytes  he  wants  to  see  dis¬ 
played.  It  then  provides  a  hexadecimal  and 
ASCII  display  of  the  contents  of  the  selected 
area  of  memory  on  the  terminal. 

menuO 

inain.c 

Displays  the  first  in  a  hierarchy  of  menus 
permitting  the  user  to  test  subsystems  of  the 
Vibro-acoustic  Experiment  individually. 

monitor_heatersO 

expmnt.c 

Operates  the  heaters  if  the  temperature  of 
the  bubble  memory  is  too  cold.  If  the  tem¬ 
perature  is  too  hot,  it  shuts  the  heaters  off. 
Otherw'ise  it  leaves  the  heaters  alone. 

outputO 

newio.s 

Outputs  a  byte  to  a  port.  Written  in  assem¬ 
bly  language,  but  used  like  a  C  language 
routine. 

portdumpO 

inout.c 

Outputs  a  string  to  the  terminal. 

postJaunchO 

expmnt.c 

Conducts  routine  monitoring  of  events  upon 
the  completion  of  the  Vibro-acoustic  Exper¬ 
iment.  These  functions  continue  until  the 
Space  Shuttle  returns  to  earth,  or  until  the 
lOV  bus  no  longer  carries  sufTicient  voltage 
for  safe  operation  of  the  bubble  memories. 

In  the  latter  case,  the  experiment  stops  all 
operations. 

po>ver_status() 

power.c 

Inputs  the  one-byte  status  code  from  the 
power  relay  subsystem. 

power  write() 

power.c 

Sends  a  one-byte  command  code  to  the 
power  relay  subs>  stem. 

pwrcntO 

power.c 

A  menu  program  which  let’s  the  user  read 
the  status  code  from  the  power  relay  subsys¬ 
tem  or  send  commands  to  it. 

rdstatregO 

bubble.c 

Reads  the  status  register  of  the  bubble 
memory  controller. 

recordO 

expmnt.c 

Performs  the  record  phase  of  the  abridged 
experiment. 

rtcO 

cIock.c 

A  menu  routine  allowing  the  user  to  set  or 
read  the  clock,  and  to  test  the  time-out  fea¬ 
ture  (see  testtimeoutO  in  this  table). 

short_experimentO 

expmnt.c 

Performs  the  abridged  Vibro-acoustic  Ex¬ 
periment. 
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showbubbuffQ 

bubble.c 

A  buffer  exists  in  the  controller's  memorx'  to  | 
hold  a  copy  of  data  transferred  to  or  from 
the  bubble  memory.  This  routine  displays 
the  contents  of  that  buffer  either  in  ASCII 
characters  or  hexadecimal. 

sbow_event() 

expmnt.c 

Converts  an  event  code  into  an  intelligible 
message  which  it  then  displays  on  the  termi¬ 
nal. 

sbo>v_waketime() 

clock.c 

Displays  the  date  and  time  when  a  time-out 
will  end. 

sbut_down() 

expmnt.c 

Removes  power  from  any  subsystems  which 
presently  have  power.  It  makes  a  log  entry 
for  each  such  case. 

sbut_do>vn_no_log() 

expmnt.c 

Removes  power  from  any  subsystems  which 
presently  ha\e  power.  It  makes  no  log  entry' 
of  its  actions. 

ssdrmodeO 

expmnt.c 

Issues  commands  to  the  Solid  State  Data 
Recorder  (SSDR)  to  enter  various  modes  of 
operation. 

ssdr_status() 

expmnt.c 

Obtains  the  status  code  from  the  Solid  State 
Data  Recorder  (SSDR). 

terminO 

inout.c 

Inputs  a  single  character  from  the  terminal. 

testinputO 

inout.c 

.Asks  the  user  for  a  he.xadecimal  port  address, 
reads  that  port  and  displays  the  data  read 
from  that  port. 

testioO 

main.c 

This  routine  permits  the  user  to  perform  in¬ 
put  from  and  output  to  any  port  in  the  sys¬ 
tem.  By  ‘‘port“  we  mean  here  an  address  in 
the  input  and  output  space. 

testoutputO 

inout.c 

.Asks  the  user  for  a  hexadecimal  port  address 
and  a  hexadecimal  byte  to  be  sent  lO  the 
port,  and  sends  it  there. 

testpatternO 

bubble.c 

A  buffer  exists  in  the  controller's  memory  to 
hold  a  copy  of  data  transferred  to  or  from 
the  bubble  memory  .  This  routine  permits 
the  user  to  modify  the  contents  of  that 
buffer. 

testtimeoutO 

clock.c 

Lets  the  user  test  the  time-out  feature.  For 
example,  he  can  request  a  delay  of  15  sec¬ 
onds.  During  this  delay,  the  control  pro¬ 
gram  will  not  respond  to  input.  At  the  end 
of  this  period,  it  will  display  the  current  date 
and  time. 

timeoutO 

clock.c 

In  one  mode  of  operation,  this  function 
computes  a  “wake-up”  time  based  on  the 
current  time  and  a  specified  delay.  In  an¬ 
other  mode,  it  checks  to  see  if  a  “wake-up” 
time  computed  earlier  has  arrived  or  not. 

tolowerQ 

convert.c 

Converts  upper  case  characters  to  lower 
case.  Non-alphabetic  characters  are  not 
changed.  This  subroutine  is  from  Bilofsky 
[Ref.  18). 

uitohQ 

convert.c 

Converts  an  unsigned  integer  to  the  corre¬ 
sponding  hexadecimal  ASCII  string  repre¬ 
sentation.  For  example,  45  is  converted  to 
“2D” 

versionO 

version.c 

Displays  the  current  version  number  of  the 
control  program  on  the  terminal. 

voltages_lo>v() 

expmnt.c 

Checks  the  lOV  bus.  If  the  voltage  has  fallen 
too  low,  this  function  returns  the  value 

TRUE;  otherwise  it  returns  the  value 

FALSE. 

we_launched() 

expmnt.c 

Checks  for  any  indications  of  a  launch. 

These  can  come  from  the  Vibration-activated 
Launch  Detector  or  from  the  Barometric 
Pressure  Switches. 

APPENDIX  F.  SUBROUTINES,  IN  ALPHABETICAL  ORDER  WITHIN 

EACH  MODULE 

Table  9.  MS/DOS  FILE  INDEX:  This  table  shows  the  names  of  the  files  in  the 


MS,  DOS  files.  Subroutines  are  listed  alphabetically  by  name  within  each 
file  group. _ 


SOURCE 

FILE 

SUBROUTINE 

PURPOSE 

bubble.c 

bpagesetO 

Loads  the  five  parametric  registers  in  the 
bubble  memoiy  controller.  Most  of  these 
never  change.  Two.  however,  do  change  of¬ 
ten.  These  two  specify  the  page  of  bubble 
memoiy-  where  transfers  of  data  begin.  Call 
this  function  prior  to  any  operation  per¬ 
forming  input  from  or  output  to  the  bubble 
memory  to  ensure  the  parameters  are  cor¬ 
rectly  specified. 

bubble.c 

bubcmdmenuO 

Displays  a  menu  of  low-level  bubble  memory 
controller  conunands.  These  are  useful  in 
testing  the  bubble  memory  for  proper  oper¬ 
ation. 

bubble.c 

bubinitO 

Initializes  the  bubble  memory  prior  to  its 
being  used.  This  initialization  must  always 
be  done  after  power  is  applied  and  before 
input  and  output  operations  begin. 

bubble.c 

bubio() 

Performs  input  from  and  output  to  the  bub¬ 
ble  memoiy. 

bubble.c 

bubmenuO 

Provides  a  menu  of  functions  permitting  the 
user  to  perform  operations  with  the  bubble 
memory.  These  operations  include: 

1.  applying  and  removing  power, 

2.  initialization, 

3.  input, 

4.  output  and 

5.  reading 

the  status  of  the  bubble  memory'. 

bubble.c 

bub_off() 

Removes  power  from  the  bubble  memory. 

bubble.c 

bub_on() 

.Applies  power  to  the  bubble  memory. 
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bubble.c 

issububcmdO 

Issues  commands  to  the  bubble  memory 
controller  and  analyzes  the  status  codes 
which  result.  In  many  cases,  it  will  attempt 
to  issue  a  command  repeatedly  if  there  is 
some  failure,  doing  this  up  to  a  specified 
number  of  times.  This  routine  is  written  in 

C  and  is  not  fast  enough  to  handle  the  read 
and  write  commands.  Use  bubreadQ  and 
bubwriteO  for  these. 

bubble.c 

rdstatregO 

Reads  the  status  register  of  the  bubble 
memory  controller. 

bubble.c 

showbubbuffO 

A  buffer  exists  in  the  controller's  memory  to 
hold  a  copy  of  data  transferred  to  or  from 
the  bubble  memorv'.  This  routine  displays 
the  contents  of  that  buffer  either  in  ASCII 
characters  or  hexadecimal. 

bubble.c 

testpatternO 

A  buffer  exists  in  the  controller’s  memory  to 
hold  a  copy  of  data  transferred  to  or  from 
the  bubble  memory.  This  routine  permits 
the  user  to  modify  the  contents  of  that 
buffer. 

bubrw.s 

bubreadO 

Takes  care  of  the  actual  transfer  of  data  from 
the  bubble  memory  to  the  controller  memory 
during  a  read.  This  routine  was  written  in 
assembly  language  in  order  to  achieve  a  data 
transfer  rate  of  16  K  bytes  per  second  im¬ 
posed  by  the  bubble  memory  hardware. 

bubnv.s 

bub>vrite() 

Takes  care  ol'the  actual  transfer  of  data  to 
the  bubble  memory  from  the  controller 
memory  during  a  write.  This  routine  was 
written  in  assembly  language  in  order  to 
achieve  a  data  transfer  rate  of  16  K  bytes  per 
second  imposed  by  the  bubble  memory 
hardware. 

bubn^.s 

bubxferO 

Part  of  the  sequence  of  steps  necessary  to 
initialize  the  bubble  memory  entails  trans¬ 
ferring  the  byte  Oxff  to  the  bubble  memoiy 

40  times.  This  routine  does  this.  The  rou¬ 
tine  is  written  in  assembly  language  for 
speed,  but  is  called  in  the  same  manner  as  a 

C  routine. 

clock.c 

clockcompareO 

Compares  two  clock  times  to  see  which  one 
is  later  than  the  other. 

cIock.c 

cIockintQ 

Dates  and  times  in  the  real  time  clock  are 
stored  in  BCD  format.  This  routine  converts 
them  to  integer  format  to  make  it  convenient 
to  perform  arithmetic  with  them.  Thus,  fu¬ 
ture  dates  and  times  can  be  computed. 
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cIock.c 

clockreadQ 

Reads  the  current  date  and  time  from  the 
real  time  clock. 

clock.c 

clocksetQ 

Sets  the  current  date  and  time  in  the  real 
time  clock  according  to  values  specified  by 
the  user. 

cIock.c 

clocksumQ 

Adds  two  dates  and  times  together  to 
produce  a  new  date  and  time.  In  practice, 
one  uses  this  to  calculate  a  future  date  and 
time  from  the  current  date  and  time  and 
some  desired  delay  (e.g.,  15  minutes). 

ciock.c 

dump_clock() 

Display  the  date  and  time  on  the  terminal. 

clock.c 

dumpJclockO 

Display  the  date  and  time  on  the  terminal. 

This  differs  from  dump_clock()  in  that  the 
dates  and  times  it  uses  are  integers,  not  Bi¬ 
nary  Coded  Decimal  (BCD)  numbers. 

ciock.c 

get_time() 

Obtain  a  valid  date  and  time  from  the  user. 

clock.c 

rtc() 

A  menu  routine  allowing  the  user  to  set  or 
read  the  clock,  and  to  test  the  time-out  fea¬ 
ture  (see  testtimeoutO  in  this  table). 

clock.c 

sho>v_«aketime() 

Di<;plays  the  date  and  time  when  a  time-out 
will  end. 

clock.c 

testtimeoutO 

Lets  the  user  test  the  time-out  feature.  For 
example,  he  can  request  a  delay  of  15  sec¬ 
onds.  During  this  delay,  the  control  pro¬ 
gram  will  not  respond  to  input.  At  the  end 
of  this  period,  it  will  display  the  current  date 
and  time. 

clock.c 

timeoutO 

In  one  mode  of  operation,  this  function 
computes  a  “wake-up"  time  based  on  the 
current  time  and  a  specified  delay.  In  an¬ 
other  mode,  it  checks  to  see  if  a  “wake-up" 
time  computed  earlier  has  arrived  or  not. 

convert.c 

atoh() 

Converts  an  .ASCII  string  representation  of 
a  hexadecimal  byte  into  the  corresponding 
hexadecimal  byte.  For  example,  the  string 
“a3”  is  converted  to  the  byte  value  0xa3. 

convert.c 

atohexintQ 

Converts  a  four-byte  ASCII  string  repres¬ 
enting  a  tw’o-byte  hexadecimal  word  into  the 
corresponding  hexadecimal  word.  For  ex¬ 
ample,  the  string  “a34b”  is  converted  to  the 
word  Oxa34b. 

convert.c 

atoi() 

Converts  a  string  representing  a  decimal  in¬ 
teger  into  the  corresponding  integer.  This 
subroutine  is  from  Bilofsky  (Ref  18). 
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convert.c 

bcd_asc() 

Converts  a  BCD  byte  to  the  corresponding 
character  string  representation.  For  exam¬ 
ple,  0x17  is  converted  to  “IT'’. 

convert.c 

bcd_int() 

Converts  a  one-byte  BCD  number  to  integer 
format. 

convert.c 

ctoh() 

Converts  a  single  character  to  its 
hexadecimal  ASCII  string  representation. 

For  example.  0xa3  is  converted  to  “aS”. 

convert.c 

int_bcd() 

Converts  an  integer  in  the  range  0  through 

99  to  BCD  format. 

convert.c 

itoa() 

Converts  an  integer  to  an  ASCII  string  rep¬ 
resentation.  This  subroutine  is  from  Bilofsky 
(Ref  18). 

convert.c 

tolowerO 

Converts  upper  case  characters  to  lower 
case.  Non-alphabetic  characters  are  not 
changed.  This  subroutine  is  from  Bilofskv 
(Ref  18). 

convert.c 

uitohO 

Converts  an  unsigned  integer  to  the  corre¬ 
sponding  hexadecimal  .^SCll  string  repre¬ 
sentation.  For  example.  45  is  converted  to 
•‘2D" 

delay.s 

dehyO 

Provides  a  software-driven  time  delay  in  in¬ 
crements  of  10  ms.  Written  in  assembly 
language,  but  used  like  a  C  language  routine. 
.Adapted  from  a  program  by  .\Ir.  David 
Rigmaiden  of  the  Naval  Postgraduate 

School. 

expmnt.c 

ad_read() 

Gets  a  character  of  data  from  the  Analog- 
to-digital  (A  D)  Converter. 

expmnt.c 

adtointO 

Converts  a  character  of  raw  data  from  the 
.•\nalog-to-digital  {.A  D)  Converter  into  an 
integer  format  with  the  more  meaningful 
units  of  volts  or  degrees  kelvin. 

expmnt.c 

alter_pageO() 

Permits  the  user  to  alter  the  contents  of  page 

0  of  the  bubble  memorx’.  This  is  required  in 
initializing  the  experiment. 

expmnt.c 

badJdea_to_record() 

This  routine  is  used  in  the  abridged  exper¬ 
iment  to  prevent  record  mode  from  being  re¬ 
started  after  a  power  fault.  Without  this 
safeguard,  perfectly  good  data  recorded  dur¬ 
ing  launch  might  be  erased. 

expmnt.c 

baro_switch() 

Checks  to  see  if  the  barometric  switches  have 
been  activated  yet.  If  so,  launch  must  have 
occurred  and  an  appropriate  log  entry  is 
made. 

expmnt.c 

checkprtO 

Checks  to  see  whether  or  not  there  is  a  ter¬ 
minal  connected  to  the  RS-232C  serial  inter¬ 
face  port. 

exptnnt.c 

colder_thanO 

Returns  the  value  TRUE  if  the  bubble 
memory  ’s  temperature  is  below  the  temper¬ 
ature  given  in  the  argument  to  the  function, 
FALSE  otherwise. 

expmnt.c 

display_data_page() 

Displays  the  contents  of  any  page  in  the 
bubble  memory  in  a  readable  format.  It  will 
not  successfully  display  page  0.  Use 
display_page0O  for  this  purpose. 

expmnt.c 

display_pageO() 

Displays  the  contents  of  page  0  in  a  readable 
format. 

expmnt.c 

do_s«eep() 

Causes  the  sweep  phase  of  the  experiment  to 
be  performed. 

expmnt.c 

expmntO 

Causes  the  Vibro-acoustic  Experiment  to  be 
performed. 

expmnt.c 

listenO 

Listens  for  the  .Auxiliary  Power  Units 
(.APUs)  to  be  activated.  It  also  monitors  the 
Vibration-activated  Launch  Detector  and 
the  Barometric  Pressure  Switches  to  see  if  a 
launch  has  occurred  without  detection  of  the 
activation  of  the  .APUs. 

expmnt.c 

logeventO 

Makes  entries  into  the  event  log  stored  in  the 
bubble  memory. 

expmnt.c 

log_menu() 

Displays  a  menu  to  provide  for  conveniently 
changing  the  contents  of  bubble  memoiy. 

This  is  essential  for  properly  initiating  the 
experiment. 

expmnt.c 

monitor_heaters() 

Operates  the  heaters  if  the  temperature  of 
the  bubble  memory  is  too  cold.  If  the  tem¬ 
perature  is  too  hot.  it  shuts  the  heaters  off. 
Otherwise  it  leaves  the  heaters  alone. 

expmnt.c 

postJaunchO 

Conducts  routine  monitoring  of  events  upon 
the  completion  of  the  Vibro-acoustic  Exper¬ 
iment.  These  functions  continue  until  the 
Space  Shuttle  returns  to  earth,  or  until  the 
lOV  bus  no  longer  carries  sufficient  voltage 
for  safe  operation  of  the  bubble  memories. 

In  the  latter  case,  the  experiment  stops  all 
operations. 

expmnt.c 

recordO 

Performs  the  record  phase  of  the  abridged 
experiment. 

expmnt.c 

short_experiment() 

Performs  the  abridged  Vibro-acoustic  Ex¬ 
periment. 
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expmnt.c 

sho«_event() 

Converts  an  event  code  into  an  intelligible 
message  which  it  then  displays  on  the  termi¬ 
nal. 

expmnt.c 

shut_down() 

Removes  power  from  any  subsystems  which 
presently  have  power.  It  makes  a  log  entry 
for  each  such  case. 

expmnt.c 

shut_doMTi_noJogO 

Removes  power  from  any  subsystems  which 
presently  have  power.  It  makes  no  log  entry 
of  its  actions. 

expmnt.c 

ssdrmodeO 

Issues  commands  to  the  Solid  State  Data 
Recorder  (SSDR)  to  enter  various  modes  of 
operation. 

expmnt.c 

ssdr_status() 

Obtains  the  status  code  from  the  Solid  State 
Data  Recorder  (SSDR). 

expmnt.c 

voltages_lo\>() 

Checks  the  lOV  bus.  If  the  voltage  has  fallen 
too  low,  this  function  returns  the  value 

TRUE;  otherwise  it  returns  the  value 

F.ALSE. 

expmnt.c 

MeJaunchedO 

Checks  for  any  indications  of  a  launch. 

These  can  come  from  the  Vibration-activated 
Launch  Detector  or  from  the  Barometric 
Pressure  Switches. 

fputc.c 

fputcO 

The  UNI  WARE  compiler  provides  the 
standard  C  output  routine  printf()  to  provide 
output  to  the  standard  output  device.  How¬ 
ever,  this  routine  requires  the  user  to  provide 
a  routine  fputcQ  to  handle  the  output  of  a 
single  character  to  any  arbitrary  device.  We 
only  support  output  by  fputc()  to  the 

RS-232C  terminal,  so  this  routine  is  specific 
to  that  device.  The  routine  will  not  output 
a  character  if,  upon  checking,  it  finds  there 
is  no  terminal  attached  to  the  serial  interface 
port.  Thus,  when  the  e.xperiment  is  operat¬ 
ing,  calls  to  printfO  are  of  no  effect  unless 
there  is  a  terminal  connected. 

initiaLc 

inithard»are() 

Initializes  the  six  ports  on  NSC810A  t!;l  and 
#2. 

inout.c 

alIow_ctrIJnternipts() 

Processes  the  special  characters  CTRL  S  and 
CTRL  Y  when  read  from  the  keyboard. 

CTRL  S  is  a  toggle  switch.  The  first  time  it 
is  pressed,  the  display  halts.  The  second  time 
it  is  pressed,  the  display  resumes.  Subse¬ 
quently  its  function  alternates  between  these 
two.  CTRL  Y  invokes  the  diagnostic  sub¬ 
system. 

inout.c 

dumpO 

Produces  a  hexadecimal  and  ASCII  dump 
of  any  desired  region  of  memon.'. 

inout.c 

echo() 

Sends  a  single  character  to  the  terminal. 

inout.c 

gethexO 

Inputs  a  string  representation  of  a  two-digit 
hexadecimal  number  from  the  terminal  and 
converts  it  to  hexadecimal  format.  For  ex¬ 
ample,  “3a”  is  converted  to  0x3a. 

inout.c 

gethexintO 

Gets  a  four-digit  hexadecimal  number  in 
string  format  from  the  terminal  and  converts 
it  to  a  hexadecimal  word.  For  example, 
“3ab2”  is  converted  to  Ox3ab2. 

inout.c 

getintO 

Inputs  a  string  representation  of  a  decimal 
integer  from  the  terminal  and  converts  it  to 
integer  format.  For  example,  “352"  is  con¬ 
verted  to  352. 

inout.c 

getpagenoO 

Asks  the  user  for  a  page  number  in  bubble 
memorx'. 

inout.c 

iook_ahead() 

This  program  can  see  whether  a  character 
has  been  input  from  the  keyboard  without 
disturbing  the  input  buffer. 

inout.c 

portdumpO 

Outputs  a  string  to  the  terminal,  interface 
port. 

inout.c 

termini) 

Inputs  a  single  character  from  the  terminal. 

inout.c 

testinputl) 

Asks  the  user  for  a  hexadecimal  port  address, 
reads  that  port  and  displays  the  data  read 
from  that  port. 

inout.c 

testoutputO 

.Asks  the  user  for  a  hexadecimal  port  address 
and  a  hexadecimal  byte  to  be  sent  to  the 
port,  and  sends  it  there. 

main.c 

main() 

First  C  language  subroutine  to  get  control 
after  start-up.  Decides  whether  to  invoke 
the  menu-driven  diagnostic  routines  or  to 
run  The  Vibro-acoustic  Experiment. 

mbrk.s 

mbrk() 

Implements  the  C  language  standard  library 
function  mbrk().  This  function  was  provided 
with  the  Uniware  C  Compiler. 

main.c 

memory_dump() 

Asks  the  user  for  an  address  in  memory  and 
the  number  of  bytes  he  wants  to  see  dis¬ 
played.  It  then  provides  a  hexadecimal  and 
ASCII  display  of  the  contents  of  the  selected 
area  of  memory  on  the  terminal. 

main.c 

menu() 

Displays  the  first  in  a  hierarchy  of  menus 
permitting  the  user  to  test  subsystems  of  the 
Vibro-acoustic  Experiment  individually. 
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inain.c 

testio() 

This  routine  permits  the  user  to  perform  in¬ 
put  from  and  output  to  any  port  in  the  sys¬ 
tem.  By  "port”  we  mean  here  an  address  in 
the  input  and  output  space. 

ne»io.s 

input() 

Inputs  a  character  from  a  port.  Written  in 
assembly  language,  but  used  like  a  C  lan¬ 
guage  routine. 

ne>vio.s 

outputQ 

Outputs  a  byte  to  a  port.  Written  in  assem¬ 
bly  language,  but  used  like  a  C  language 
routine. 

power.c 

power_status() 

Inputs  the  one-byte  status  code  from  the 
power  relay  subsystem. 

power.c 

power_>vrite() 

Sends  a  one-byte  command  code  to  the 
power  relay  subsystem. 

power.c 

p>vrcnt() 

A  menu  program  which  let's  the  user  read 
the  status  code  from  the  power  relay  subsys¬ 
tem  or  send  commands  to  it. 

version.c 

versionO 

Displays  the  current  version  number  of  the 
control  program  on  the  terminal. 
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APPENDIX  G.  CONTROL  PROGRAM  DOCUMENTATION 


We  presented  a  general  description  of  the  software  as  a  whole  in  Chapter 
IV.  DESIGN  OF  THE  CONTROL  SOFTWARE  on  page  43.  This  included  a  mod¬ 
erately  detailed  description  of  the  flowcharts  which  describe  the  system,  beginning  with 
Flowchart  0  in  Figure  20  on  page  48.  This  appendix  contains  more  detailed  de¬ 
scriptions  of  the  operation  of  each  subroutine  in  the  control  program.  A  basic  know¬ 
ledge  of  the  C  programming  language  is  assumed. 

We  have  grouped  the  functions  into  two  broad  categories: 

1.  major  subroutines,  and 

2.  support  subroutines. 

The  descriptions  in  this  appendix  are  best  understood  by  referring  to  the  source  code  in 
APPENDIX  H.  CONTROL  PROGR.AM  SOURCE  CODE  on  page  150. 

In  Section  A.  Major  Subroutines  and  Functions  on  page  108  we  present  the  major 
subroutines  and  functions  of  the  control  program  in  an  order  based  roughly  on  their 
position  in  the  hierarchy  of  function  calls.  This  section  therefore  follows  the  overall 
structure  of  the  control  program. 

Referring  again  to  Flowchart  0  in  Figure  20  on  page  48,  we  see  that  the  control 
program  contains  two  major  parts; 

1.  One  performs  the  Vibro-acoustic  Experiment. 

2.  The  other  operates  a  menu-driven  system  to  permit  testing  of  the  system  on  the 
ground. 

Once  we  have  discussed  the  major  subroutines,  there  will  remain  numerous  lesser 
subroutines  which  we  describe  in  Section  B.  Supporting  Subroutines  and  Functions  on 
page  121.  We  provide  two  tables  to  make  it  easier  quickly  to  ascertain  the  purpose  of 
subroutines  and  their  locations  in  several  different  source  files.  Table  8  on  page  91  lists 
all  subroutines  by  name,  and  shows  in  which  .MS,  DOS  source  files  subroutines  are  lo¬ 
cated.  Table  9  on  page  99  lists  the  contents  of  each  .MS;DOS  source  file  in  alphabetic 
order  by  name. 

In  general,  the  program  attempts  to  display  many  diagnostic  messages  on  the  ter¬ 
minal  using  the  printfO  function.  This  function  was  supplied  with  the  C  compiler,  but 
it  in  turn  calls  a  function  called  fputc()  noi  supplied  with  the  compiler.  The  purpose  of 
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the  subroutine  fputcQ  is  to  accept  a  character  from  the  printf()  function  and  to  send  it 
to  the  terminal  for  display.  We  created  this  subroutine,  and  its  description  is  contained 
in  Section  B.  Supporting  Subroutines  and  Functions  on  page  121.  This  function  al¬ 
ways  checks  to  see  whether  there  is  a  terminal  attached  or  not.  If  not,  it  makes  no  at¬ 
tempt  to  display  any  messages  on  the  terminal.  Henceforth,  whenever  we  say  that 
something  will  appear  on  the  terminal,  it  will  be  understood  that  this  will  only  occur  if 
the  terminal  is  attached. 

A.  MAJOR  SUBROUTINES  AND  FUNCTIONS 
1.  main() 

This  is  the  beginning  point  for  any  C  language  program.  It  is  called  by  the 
start-up  code,  which  is  written  in  Z-80  assembly  language.  The  main()  program  first 
initializes  pointers  to  the  buffers  which  will  hold  data  from  the  bubble  memor>'.  There 
are  two  formats  for  such  data.  One  is  used  in  page  zero  of  the  memoiy  ,  which  is  used 
to  record  the  current  status  of  the  experiment.  The  other  format  is  used  in  all  other 
pages  of  the  bubble  memor>‘  to  record  all  actions  and  measurements  taken  during  the 
experiment.  The  buffers  are  treated  both  as  arrays  and  as  structures.  When  they  are 
treated  as  arrays,  it  is  easy  to  transfer  the  data  to  or  from  the  bubble  memory.  When 
they  are  treated  as  structures,  it  is  easy  to  e.xtract  individual  fields  of  data.  By  forcing 
the  pointers  pagezero  and  log_page  to  point  to  the  arrays  pageO_buffer  and  Iog_buffer 
respectively,  we  can  access  the  data  subsequently  by  using  either  the  pointer  to  the 
structure  or  the  name  of  the  array  as  appropriate. 

The  niainO  program  then  calls  inithardwareO  to  initialize  the  two  NSC810A 
R.'Wl-I  O  Timer  chips  on  the  controller  board.  Ne.xt  it  checks  to  see  if  there  is  a  ter¬ 
minal  attached  by  calling  checkprt().  The  absence  of  a  terminal  implies  that  the  appa¬ 
ratus  is  now  installed  in  the  Space  Shuttle  and  the  controller  should  therefore  perform 
the  experiment.  Therefore,  if  there  is  no  terminal  attached,  mainQ  will  call  e.\pmnt(), 
which  performs  the  Vibro-acoustic  Experiment. 

If  there  is  indeed  a  terminal  attached,  mainQ  calls  shut__down_nojog0,  whose 
function  is  to  remove  power  from  all  subsystems  without  logging  that  action  in  the 
bubble  memory.  The  reason  for  remc'-  ing  power  is  to  ensure  that  all  the  subsystems  are 
in  a  known  state  at  the  outset.  The  reason  for  not  wishing  to  log  this  action  is  that  the 
log  entries  should  only  be  made  during  the  course  of  the  experiment.  Since  the  con¬ 
troller  is  about  to  enter  the  menu  subsystem,  it  is  not  going  to  perform  the  experiment 
and  so  no  log  entry  is  appropriate. 


Next  main()  calls  menuO,  from  which  all  other  testable  sections  of  the  control 
program  can  be  selected.  The  option  EXPERIMENTOK  permits  the  menu  diagnostic 
subsystem  to  invoke  the  program  expmnt()  later,  if  the  user  wishes  to  do  so.  This  would 
permit  him  to  perform  the  experiment  on  the  ground  and  so  test  its  operation. 

2.  void  inithard\vare(void) 

This  subroutine  initializes  the  two  NSC810A  RAM-I  O-Timer  chips  on  the 
controller  board.  The  uses  of  the  pins  of  port  A  in  each  chip  are  given  in  Table  4  on 
page  17  and  Table  5  on  page  17;  those  of  Port  B  are  given  in  Table  2  on  page  15  and 
Table  3  on  page  16;  and  those  of  port  C  are  given  in  Table  6  on  page  18  and  Table  7 
on  page  19. 

MDRl  is  the  .Mode  Definition  Register  of  the  NSCSIO.’X  #1.  Writing  a  0x00  to 
it  puts  port  into  basic  I  O  mode,  which  is  the  simplest  method  of  1  O  supported  by 
this  chip. 22 

DDR.^!  is  the  Data  Direction  Register  of  port  A,  of  the  NSCSIO.A  ±il.  Writing 
O.xff  to  it  causes  each  of  its  bits  to  be  configured  for  output. 

DDRBI  is  the  Data  Direction  Register  of  port  B,  of  the  NSCSIO.A  =1.  Writing 
Oxir  to  it  causes  each  of  its  bits  to  be  configured  for  output. 

DDRCl  is  the  Data  Direction  Register  of  port  C,  of  the  NSCSIO.A  si.  Writing 
0x30  to  it  causes  bits  0  through  3  and  bits  6  and  7  to  be  configured  for  input.  Bits  4  and 
5  are  configured  for  output,  although  bit  5  is  not  used  in  the  Vibro-acoustic  Experiment. 
Note:  this  is  only  a  6  bit  port;  bits  6  and  7  do  not  exist. 

TMOl  is  the  register  for  setting  the  mode  of  Timer  0  in  NSCSIOA  si.  Writing 
0x00  to  it  will  stop  the  timer,  an  action  which  must  be  performed  before  changing  its 
mode.  Writing  0x25  will  cause  the  timer  to  produce  a  square  wave  without 
“prescaling"  and  with  "single  precision".  When  prescaling  is  not  used,  every  pair  of  in¬ 
put  clock  cycles  is  used  to  advance  the  timer’s  counter  by  one.  When  single  precision 
is  selected,  only  the  low  byte  of  the  timer  will  ever  be  read. 

TOLBl  and  TOHBl  are  the  registers  for  the  low  byte  and  high  byte  respectively 
of  the  modulus  for  Timer  0  in  NSC810  #1.  This  number  serves  to  initiate  the  timer 
counter.  During  subsequent  operation,  the  counter  is  decremented  once  every  clock 
period.  Each  time  the  counter  reaches  0,  the  timer  output  switches  to  the  opposite  state 
and  the  timer  is  reloaded.  We  write  0x07  to  the  low  byte  and  0x00  to  the  high  b>te,  so 
the  modulus  is  7.  This  means  that  after  every  seven  cycles,  the  clock  is  reloaded.  The 

22  With  basic  1,0,  there  is  no  handshaking  (see  Glossary)  with  support  hardware. 
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reloading  consumes  a  further  cycle,  and  it  takes  two  complete  reloads  to  go  through  one 
cycle  of  the  output.  The  period  thus  is  2  x  (7  +  1)  =  16  clock  periods.  The  NSCSOO  is 
driven  by  a  4.9152 -r  2  =  2.4576  MHz  clock.  So  16  clock  periods  take  6.51  ns,  for  a 
clock  frequency  of  ^  ~  153.6  kHz.  This  signal  is  used  as  a  baud-rate  generator 

on  the  controller  board;  it  is  fed  to  an  Intersil  6402  UART  which  further  divides  the 
frequency  by  16,  yielding  a  9600  baud  transmission  rate  at  which  to  drive  the  RS-232C 
interface. 

STARTOl  is  the  start  port  of  Timer  0  in  N'SCSIO  #1.  Writing  anything  to  this 
port  causes  the  newly  programmed  timer  to  start  operating. 

MDR2  is  the  Mode  Definition  Register  of  the  NSC810A  #2.  Writing  a  0x00  to 
it  puts  port  Aj  into  basic  I;0  mode.  This  is  the  simplest  method  of  1  O  supported  by 
this  chip.23 

DDR.A2  is  the  Data  Direction  Register  of  port  A^  of  the  NSCSIO.A  =2.  Writing 
0x00  to  it  causes  each  of  its  bits  to  be  configured  for  input. 

DDRB2  is  the  Data  Direction  Register  of  port  Bj  of  the  NSC810A  «2.  Writing 
0x00  to  it  causes  each  of  its  bits  to  be  configured  for  input. 

DDRC2  is  the  Data  Direction  Register  of  port  Q  of  the  NSC810A  ??2.  Writing 
0x31  to  it  causes  bits  1  through  3  to  be  configured  for  input.  Bits  0.  4  and  5  are  con¬ 
figured  for  output.  Bits  1  and  2  are  not  in  use.  Note:  this  is  only  a  6  bit  port;  bits  6 
and  7  do  not  exist. 

T.M02  is  the  register  for  setting  the  mode  of  Timer  0  in  NSC810A  =2.  Before 
you  can  change  the  mode,  you  must  first  stop  the  timer.  Writing  0x00  to  it  does  this. 
Writing  0x25  will  cause  the  timer  to  produce  a  square  wave  without  “prescaling"  and 
with  "single  precision".  When  prescaling  is  not  used,  every  pair  of  input  clock  cycles  is 
used  to  advance  the  timer’s  counter  by  one.  When  single  precision  is  selected,  only  the 
low  byte  of  the  timer  will  ever  be  read. 

T0LB2  and  T0HB2  are  the  registers  for  the  low  byte  and  high  byte  respectively 
of  the  modulus  of  Timer  0  in  NSC810  #2.  This  number  serves  to  initiate  the  timer 
counter.  Once  every  clock  period,  the  counter  is  decremented.  Each  time  the  counter 
reaches  0,  the  timer  output  switches  to  the  opposite  state  and  the  timer  is  reloaded. 
We  write  0x01  to  the  low  byte  and  0x00  to  the  high  byte,  so  the  modulus  is  1.  This 
means  that  after  1  cycle,  the  clock  is  reloaded.  Now  the  reloading  consumes  a  further 
cycle,  and  it  takes  two  complete  reloads  to  go  through  one  cycle  of  the  output.  The 

23  With  basic  1,0,  there  is  no  handshaking  (see  Glossaiy)  with  support  hardware. 
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period  thus  is  2  x  (1  +  1)  =  4  dock  periods.  The  NSC800  is  driven  by  a 

4.9152  +  2  =  2.4576  MHz  clock.  So  4  clock  periods  take  1.628  fis,  for  a  clock  frequency 

of  - -  614.4  kHz.  This  frequencv  is  used  as  a  clock  for  the  National  Semicon- 

1.628  ^s  ^ 

ductor  ADC0816  Analog-to-digital  (A,  D)  Converter. 

When  driven  by  a  clock  of  frequency  640  kHz,  the  A  Ds  normally  can  complete 
the  conversion  of  an  analog  signal  to  a  digital  value  in  around  100  fis.  The  frequency 
we  are  using  here,  614.4  kHz,  is  close  to  this,  so  we  should  get  comparable  performance. 
[Ref.  19:  pp.  8-71  to  8-81] 

START02  is  the  start  port  for  Timer  0  in  NSC810  #2.  Writing  anything  to  this 
port  causes  the  newly  programmed  timer  to  start  operating. 

Finally,  we  clear  bits  4  and  5  of  port  Cj  by  writing  0x03  to  the  port  Cj 
“bit  clear”  register.  BCLRC2.  The  purpose  of  this  is  to  ensure  that  power  to  the  bubble 
memory  remains  off,  and  to  ensure  that  the  bubble  memoir's  reset  line  is  held  low. 
Strictly  speaking,  this  should  not  be  necessary,  since  the  registers  of  the  NSCSIO  are  in¬ 
itialized  to  be  zeros.  However,  we  take  nothing  for  granted,  and  this  precaution  helps 
preclude  the  loss  of  the  bubble  memoiy’s  contents  that  might  result  from  an  improper 
application  of  power. 

3.  char  checkprt(void) 

This  function  inspects  the  TERMON  bit  (bit  3)  of  Port  C  in  NSCSIO  ^^2.  This 
bit  is  a  ''  if  there  is  an  RS-232C  terminal  connected  to  the  controller.  It  is  a  1  otherwise. 
The  function  returns  a  TRUE  in  the  first  case;  a  FALSE  in  the  second. 

4.  void  shut_do>vn_no_log(void) 

This  subroutine  removes  power  from  any  subsystems  which  are  currently  on. 
It  does  not  record  the  fact  in  the  bubble  memory  log,  which  is  the  only  respect  in  which 
it  differs  from  the  subroutine  sliut_do>vn().  It  obtains  a  character  describing  the  position 
of  each  of  the  relays  in  the  power  subsystem  by  calling  the  function  po«er_status().  The 
series  of  if  statements  which  then  follows  causes  successive  bits  of  that  character  to  be 
tested.  Ever>'  time  one  of  these  bits  indicates  that  a  relay  is  in  the  ‘on’  position,  that 
relay  is  turned  off  with  a  call  to  po»er_write(). 

5.  char  menu(char  experiment_flag) 

This  function  is  at  the  top  of  a  hierarchy  of  diagnostic  subroutines.  The  func¬ 
tion  calls  the  sub-function  verslonQ  whose  only  purpose  is  to  display  the  number  and 
date  of  the  current  version  of  the  control  program.  It  next  presents  a  menu  from  which 
the  user  can  select  any  of  a  number  of  categories  of  diagnostic  tests.  The  function 
terminf)  is  used  to  obtain  a  single  character  from  the  keyboard,  that  character  is  con- 


verted  to  lower  case  by  tolowerQ  (if  it  was  not  already  in  lower  case),  and  the  character 
is  displayed  on  the  terminal.  That  character  is  used  by  the  switch  to  select  a  case  state¬ 
ment  appropriate  to  the  user’s  choice.  The  entire  process  will  be  e.xecuted  repetitively. 
The  only  w'ay  to  leave  it  is  by  choosing  to  run  the  experiment.  If  this  is  done,  the 
function  e.\pmnt()  gets  control. 

To  cause  a  software  reset,  the  program  executes  an  assembler  instruction  jp  0. 
This  function  has  the  effect  of  restarting  the  controller  at  address  0  of  memory'.  This  is 
the  same  address  at  which  execution  begins  when  power  is  first  applied.  All  variables 
are  set  to  their  initial  values,  other  start-up  functions  are  performed  as  usual,  and  the 
program  main()  begins  to  execute  anew. 

The  function  rtc()  accesses  the  real-time  clock  diagnostic  subroutines. 

The  function  pwrcntf)  access  the  power  subsystem  diagnostic  subroutines. 

The  function  bubmenuf)  accesses  the  diagnostic  subroutines  which  can  be  used 
to  test  the  bubble  memory  module.  The  tests  available  through  this  selection  all  are  very' 
low-level  tests. 

When  choice  E  is  made,  the  controller  enters  a  for  loop  and  successively  reads 
each  of  the  analog-to-digital  (A  D)  converter  channels  by  calling  the  sub-function 
adreadf).  This  function  returns  an  eight-bit  number  addata  which  is  proportional  to  the 
value  read  by  the  A  D  converter.  A  call  to  printf()  displays  this  number  along  with  a 
descriptive  adcaption  (defined  in  the  file  global.c).  The  first  three  readings  are  known  to 
be  voltages.  The  remaining  values  are  temperatures,  so  they  are  displayed  in  a  slightly 
different  format.  Furthermore,  depending  on  which  channel  the  A  D  converter  read,  the 
number  read  may  represent  different  magnitudes  in  the  measured  units.  For  example, 
the  number  102  may  represent  4V  or  ZTO^K,  depending  on  which  channel  was  read. 

Voltages,  fall  either  into  the  range  (0,  lOjV  or  the  range  [0,  20]V.  Temperatures 
fall  into  the  range  (0,  5001‘’K.  The  function  adtointf)  converts  the  value  read  by  the  A  D 
converter  into  its  value  in  degrees  Kelvin  or  in  hundredths  of  volts,  whichever  is  appli¬ 
cable.  The  converted  value  is  then  displayed  using  the  printf()  function.  To  get  two 
converted  readings  per  line,  carriage  returns  are  placed  at  the  end  of  every  other  dis¬ 
played  value,  only. 

There  are  tw'o  possibilities  if  choice  F  is  made.  One  is  that  e.xperiment^flag  is 
TRUE;  the  other  is  that  it  is  FALSE.  The  former  case  alw’ays  occurs  when  menuf)  is 
called  the  first  time,  from  inain().  However,  it  is  possible  to  interrupt  the  execution  of 
the  experiment  and  to  enter  the  menu  subsystem  recursively.  It  is  not  possible  to  make 
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menu  choice  K  under  these  circumstances.  To  restart  the  experiment  would  require  first 
making  choice  A  to  reset  the  system. 

The  function  testio()  is  called  when  choice  G  is  made.  Its  purpose  is  to  allow 
low-level  testing  of  the  peripheral  devices. 

The  function  memorj’^dumpQ  is  called  when  choice  H  is  made.  Its  purpose  is 
to  display  the  contents  of  the  controller’s  memory^  This  is  useful  only  in  debugging  the 
software. 

The  function  Iog_menu()  is  called  when  choice  I  is  made.  Its  purpose  is  to  allow 
the  contents  of  the  bubble  memory  to  be  displayed.  It  differs  from  the  functions  called 
when  choice  D  is  made  in  that  the  contents  of  the  bubble  memory  are  regarded  by 
Iog_nienu()  as  formatted  data  areas,  not  just  as  collections  of  characters.  This  means 
that  the  data  stored  in  the  bubble  memory  during  execution  of  the  experiment  can  be 
displayed  in  an  intelligible  format,  and  the  experiment's  status,  stored  in  page  0.  also  can 
be  displayed  in  a  readable  format.  The  function  log_menu()  also  allows  the  status  to  be 
modified  in  order  to  alTect  the  manner  in  which  the  controller  performs  the  experiment. 
The  details  of  how  to  do  this  are  contained  in  Chapter  V.  HOW  TO  GET  THE  EX- 
PERl.VIENT  READY  FOR  A  LAUNCH  on  page  63. 

6.  void  version(void) 

This  function  displays  the  number  and  date  of  the  current  version  of  the  control 
program  on  the  terminal. 

7.  void  rtc(void) 

This  function  displays  a  menu  of  functions  related  to  the  operation  of  the  real¬ 
time  clock.  The  clock  can  be  read,  set  or  tested  from  here.  The  method  of  displaying 
the  menu,  reading  the  choice,  and  taking  the  appropriate  action  is  identical  to  that  used 
in  the  function  menuQ  described  earlier.  The  function  rtc()  differs  only  in  the  choices 
and  actions  possible. 

Choice  A  causes  the  function  clockreadQ  to  be  called.  It  stores  the  current  date 
and  time  in  a  structure  w'hose  pointer  is  clock.  The  function  dump_clock0  is  called  next; 
it  displays  the  date  and  time  on  the  terminal.  This  choice  is  provided  to  verify  that  the 
real  time  clock  is  working  correctly. 

Choice  B  causes  the  function  cIocksetQ  to  be  called.  It  permits  the  user  to  set 
the  current  date  and  time.  The  real  time  clock  is  powered  by  its  own  battery,  so  this 
option  should  seldom  be  required. 
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Choice  C  causes  the  function  testtimeout()  to  be  called.  Its  purpose  is  to  permit 
the  operation  of  the  timeout  feature  to  be  tested.  It  is  useful  only  in  debugging  the 
software. 

8.  void  clockread( struct  datetime  *your_ciock) 

This  function  inputs  the  binary-coded-decimal  (BCD)  time  from  the  real-time 
clock,  and  places  the  results  in  a  structure  pointed  to  by  your_clock..  If  the  current 
number  of  seconds  changes  between  the  start  and  end  of  reading,  it  means  that  the  clock 
has  advanced  to  a  subsequent  time.  To  preclude  the  reading  of  an  incorrect  time,  the 
input  sequence  is  repeated  in  the  hope  that  an  advance  will  not  occur  again.  This  can 
happen  up  to  10  x  TRIES  times. 

For  example,  suppose  the  time  were  9:59:59  when  the  seconds  and  minutes  were 
read.  The  clock  might  advance  to  10:00:00  before  the  hours  were  read.  Then  the  time 
read  would  appear  to  be  10:59:59.  which  is  wrong  by  one  hour.  By  reading  it  again,  we 
may  avoid  this  error,  but  there  is  no  obvious  way  to  guarantee  it  without  stopping  the 
clock.  Doing  so  would  be  disadvantageous,  since  it  would  affect  timing  relationships  in 
an  unpredictable  manner,  so  we  chose  not  to  stop  the  clock  but  to  take  our  chances  and 
try  reading  it  again. 

9.  void  dump_clock(struct  datetime  *clock) 

This  function  displays  on  the  terminal  the  time  stored  in  a  structure  pointed  to 
by  clock.  To  do  this  it  calls  the  function  bcdjnt(),  which  converts  the  BCD  values  in  the 
date  and  time  provided  by  the  real  time  clock  into  decimal  equivalents.  Tl^ese  converted 
values  are  then  displayed  by  the  function  printf(). 

10.  void  cIockset(  struct  datetime  *clock) 

This  function  first  calls  the  function  get_time()  to  ask  the  user  for  the  current 
date  and  time.  The  time  specified  is  left  in  the  structure  pointed  to  by  clock.  The  func¬ 
tion  clocksetO  then  stores  the  date  and  time  in  the  real-time  clock  by  repeated  calls  to 
output(). 

1 1.  void  testtimeout(void) 

This  allows  the  user  to  test  that  the  time-out  function  is  working.  The  time-out 
function  enables  the  control  program  to  continue  normal  processing  while  waiting  for 
some  amount  of  time  to  elapse. 

For  example,  after  launch  the  controller  will  monitor  the  Solid  State  Date  Re¬ 
corder  (SSDR)  for  completion  of  recording.  However,  it  will  also  initialize  a  time-out 
of  three  minutes,  and  will  stop  waiting  for  the  SSDR  if  this  time  should  elapse  before  the 
SSDR  signals  completion.  The  testtimeout()  function  allows  the  user  to  test  the  time-out 
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feature  for  any  number  of  seconds,  minutes  or  hours.  A  menu  is  presented  to  the  user 
using  the  same  method  already  outlined  in  the  description  of  the  function  menu().  The 
units  of  the  specified  delay  depends  on  the  menu  choice  made.  The  function  getint()  is 
called  to  obtain  the  number  of  units  of  delay  that  the  user  wants.  The  current  time  then 
is  obtained  with  a  call  to  clockreadQ,  and  it  is  displayed  on  the  terminal  with  a  call  to 
dump_cIock().  The  timeout()  function  then  is  called  to  initialize  the  delay  according  to 
the  number  of  delay  units  specified  by  the  user.  A  while  loop  calls  timeout()  repeatedly 
with  the  NULL  parameter.  This  parameter  causes  the  timeoutQ  function  to  check  to  see 
if  the  desired  wake-up  time  has  arrived  or  not.  As  long  as  it  has  not  yet  arrived,  that 
function  returns  FALSE  and  the  program  continues  to  loop.  If  other  statements  were 
provided  before  the  end  of  the  loop,  then  they  would  be  performed  repeatedly  until  the 
function  timeout()  finally  returned  TRUE,  signifying  that  the  desired  amount  of  time  had 
elapsed.  The  function  testtimeout()  has  no  such  instructions,  but  when  u;e  delay  period 
is  over,  it  rings  the  bell  and  once  again  reads  and  displays  the  current  time. 

12.  void  pwrcnt(void) 

1  his  function  displays  a  menu  to  allow  the  user  to  test  the  operation  of  the 
power  board  relays.  .Any  of  the  attached  units,  such  as  the  SSDR.  can  be  switched  on 
or  off  from  this  menu.  The  method  of  displaying  the  menu  is  the  same  as  that  already 
given  in  the  description  of  the  function  menuO-  Any  menu  choice  from  .A  through  J  is 
converted  to  a  number  in  the  range  [0.9]  by  subtracting  the  character  ’a'  from  it.  This 
number  is  then  used  as  an  inde.x  into  array  relay  to  select  the  command  to  be  issued  to 
the  power  control  subsystem  through  a  call  to  the  function  power_write().  Choice  K 
causes  the  power  subsystem's  status  to  be  read  with  a  call  to  power_status()  and  then 
displayed  on  the  terminal.  The  meaning  of  this  byte  is  shown  in  Table  2  on  page  15. 

13.  void  bubmeiiu(void) 

This  function  displays  a  menu  which  lets  the  user  test  the  bubble  memoiy  on  the 
controller  circuit  board.  The  method  of  displaying  the  menu  is  the  same  as  that  already 
given  in  the  description  of  the  function  menu(). 

Choice  A  causes  a  call  to  bub_on(). 

Choice  B  causes  a  call  to  bub_ofT0. 

Choice  C  attemps  to  initialize  the  bubble  memoiy^  with  a  call  to  bubinit().  The 
results  of  this  attempt  are  then  explained  with  a  call  to  pnntf(). 

Choice  D  causes  a  call  to  bubcmdtnenu(). 
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Choice  E  causes  a  call  to  testpattern().  The  character  string  tempbuffer  is  pro¬ 
vided  to  this  function  for  storage  of  a  string  of  characters  entered  by  the  user  from  the 
keyboard. 

Choice  F  causes  the  contents  of  tempbuffer  to  be  displayed  in  ASCII  format. 

Choice  G  causes  the  contents  of  tempbuffer  to  be  displayed  in  hexadecimal  for¬ 
mat.  This  would  be  useful  if  the  buffer  had  been  loaded  from  the  bubble  memory  and 
if  it  contained  unprintable  characters.  Such  would  be  the  case  if  the  contents  of  the 
bubble  memory  had  been  generated  by  performing  the  experiment,  since  the  experiment 
formats  the  data  in  characters  which  may  not  all  be  capable  of  being  displayed. 

Choice  H  calls  getpageno()  to  ask  the  user  which  page  of  the  bubble  memo" 
he  wishes  to  access.  It  then  calls  bubioQ  to  transfer  the  contents  of  the  buffer  into  that 
page  of  the  bubble  memory. 

Choice  I  calls  getpagenof)  to  ask  the  user  which  page  of  the  bubble  memory  he 
wishes  to  access.  It  then  calls  bubioQ  to  transfer  the  contents  of  that  page  of  the  bubble 
memory  into  the  buffer. 

Choice  J  causes  a  call  to  rdstatregf),  which  reads  and  displays  the  contents  of 
the  bubble  memory  controller’s  status  register.  The  format  of  this  register  is  discussed 
in  detail  in  (Ref.  1]. 

14.  char  bub_on(void) 

This  function  applies  power  to  the  bubble  memory  on  the  controller  circuit 

board. 

15.  void  bub_off(void) 

This  function  removes  power  from  the  bubble  memory  on  the  controller  circuit 

board. 

16.  char  bubinit(void) 

This  subroutine  initiates  the  bubble  memory  on  the  controller  circuit  board. 
Power  must  have  been  applied  first.  The  sequence  of  commands  is  described  in 
[Ref.  1:  pp.  38-39b].  It  is  as  follows: 

1.  Issue  the  BABORT  (abort)  command  to  the  bubble  memory. 

2.  Set  up  the  parametric  registers,  pointing  to  page  0  of  the  bubble  memory. 

3.  Issue  the  BINT T  (bubble  initialize)  command. 

4.  Issue  the  BFIFORESET  (bubble  FIFO  reset)  command  to  reset  the  first-in,  first- 

out  (FIFO)  buffer  in  the  controller’s  bubble  memory. 

5.  Transfer  40  Oxff  characters  to  the  FIFO  buffer  in  the  bubble  memory. 


6.  Issue  the  BWRBLREG  (bubble  write  boot  loop  register)  command.  At  this  point, 

the  bubble  memor\’  is  ready  for  reading  and  writing. 

17.  void  bubcmdmenu(void) 

This  subroutine  allows  the  user  to  issue  any  of  the  following  commands  to  the 
bubble  memory,  one  at  a  time: 

1.  Abort 

2.  Load  parametric  registers 

3.  Initialize 

4.  Reset  the  FIFO  buffer 

5.  Perform  the  transfer  of  40  OxfT characters  to  the  FIFO 

6.  Write  the  hoot  loop  register 

These  commands  are  issued  by  bubinit(),  but  are  provided  separately  here  to  permit  de¬ 
tailed  testing  of  the  initialization  process. 

18.  void  testpattern(char  buffer[  ]) 

This  subroutine  permits  the  user  to  fill  a  buffer  in  RAM  with  characters  to  be 
written  to  the  bubble  memory.  Up  to  PAGELENGTH  characters  can  be  written  at  a 
time.  Its  purpose  is  to  enable  the  user  to  verify  that  data  can  be  written  to  the  bubble 
memoiy  and  read  back  successfully  later. 

This  subroutine  begins  by  placing  a  0  in  the  variable  c.  It  asks  the  user  to  enter 
a  string  of  characters  from  the  keyboard,  and  then  enters  a  loop.  It  will  continue  reading 
up  to  PAGELENGTH  characters.  If  it  encounters  a  carriage  return,  it  will  place  blanks 
in  the  remainder  of  the  buffer. 

19.  void  showbubbuff(char  buffer[  },  char  mode) 

This  subroutine  will  display  the  contents  of  buffer  either  in  ASCII  format  or  in 
hexadecimal  representation,  according  to  the  value  of  mode.  This  parameter  can  be  ei¬ 
ther  ASCII  or  HEX.  The  ASCII  format  would  be  suitable  if  it  were  known  that  the 
bubble  memory  page  buffer  contained  only  printable  characters,  as  it  would  if  it  had 
been  filled  by  testpattemQ-  The  hexadecimal  format  would  be  suitable  if  it  were  known 
that  the  bubble  memory  page  previously  read  contained  unprintable  characters,  or  if  the 
contents  were  unknown.24 

24  It  may  be  unwise  to  risk  sending  potentially  unprintable  characters  to  the  terminal,  since 
some  of  them  have  surprising  results,  such  as  clearing  the  screen. 
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20.  char  bubio(char  command,  int  page,  char  ^buffer) 

This  subroutine  permits  reading  from  or  writing  to  any  page  of  the  bubble 
memoiy.  Pages  can  fall  in  the  range  0  through  8191.  Commands  can  be  either  one  of 
BREAD  or  BWRITE.  The  data  is  placed  into  or  read  from  the  buffer  pointed  to  by 
buffer. 

To  operate  the  bubble  memory  when  the  temperature  falls  below  10°  C  may 
cause  its  contents  to  be  destroyed.  A  call  to  the  function  coIder_than()  precludes  this 
from  happening.  If  that  function  returns  TRUE,  then  it  must  be  too  cold.  The  function 
bubio  returns  a  FALSE  to  indicate  that  it  was  unsuccessful  in  accessing  the  bubble 
memoiy-. 

To  minimize  power  consumption,  the  subroutine  applies  power  to  the  bubble 
memory  before  the  operation  begins  and  removes  it  again  at  the  end  of  the  transfer.  It 
calls  bpagesetO  to  set  the  parametric  registers  so  as  to  allow  the  correct  page  of  bubble 
memory  to  be  transferred.  It  then  calls  bubreadf)  or  bub\vrite()  as  appropriate.  After  the 
transfer  is  completed,  the  subroutine  reads  the  bubble  status  register  to  see  if  the  oper¬ 
ation  was  successful  or  not.  The  bubioO  subroutine  returns  a  TRUE  if  the  transfer 
worked;  F.ALSE  othenvise. 

21.  void  rdstatreg(void) 

This  subroutine  lets  the  user  check  the  contents  of  the  bubble  memory  status 
register.  The  meaning  of  its  contents  is  shown  in  Table  10  on  page  119.  To  obtain  the 
status  code,  this  subroutine  calls  the  function  inputQ,  which  reads  the  contents  of  the 
port  BUBCTRL  (port  0x41).  This  port  yields  the  status  code,  which  is  then  converted 
to  hexadecimal  format  using  the  function  ctoh()  and  is  displayed. 

22.  void  e.\pmnt(void) 

This  function  performs  the  experiment.  Its  first  task  is  to  call  initializeQ.  This 
subroutine  retrieves  the  current  mission  status  from  page  0  of  the  bubble  memory.  If 
there  is  no  more  room  in  the  bubble  memory,  a  value  of  FALSE  will  be  returned.  Al¬ 
though  the  experiment  will  be  performed,  no  entries  can  be  made  in  the  log.  The  Solid 
State  Data  Recorder  (SSDR)  may  therefore  still  be  able  to  record  acoustic  data  suc¬ 
cessfully.  There  will  be  no  log  of  the  events  as  they  occur,  however. 

The  function  expmntQ  next  checks  to  see  whether  the  flag  full_experiment  in 
page  0  is  TRUE  or  FALSE.  If  not,  the  function  short_exp€riment()  is  called  to  perform 
the  abridged  experiment.  Otherwise,  the  unabridged  experiment  is  to  be  performed  by 
expmnt(). 
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Table  10.  BIT  ASSIGNMENTS  FOR  THE  BUBBLE  MEMORY  CONTROLLER 
_ (BMC)  STATUS  BYTE:  From  (Ref.  1  :  Chapter  3.  p.  12j. _ 


Bit 

Value 

Meaning 

0 

1 

FIFO  Ready.  The  FIFO  buffer  is  ready 
to  transfer  data. 

0 

The  FIFO  buffer  is  not  ready. 

1 

1 

Parity  error. 

0 

No  parity  error. 

2 

1 

Uncorrectable  error. 

0 

No  uncorrectable  error. 

3 

1 

Timing  error. 

0 

No  timing  error. 

4 

1 

OP  FAIL.  The  current  operation  failed. 

0 

No  OP  FAIL. 

5 

1 

OP  CO.MPLETE.  The  current  operation 
is  complete. 

0 

No  OP  CO.MPLETE. 

6 

I 

Busy.  This  means  that  a  command  has 
been  accepted  but  is  not  yet  complete. 

The  B.MC  stays  busy  throughout  a  data 
transfer. 

0 

Not  busy. 

The  next  step  is  to  initiate  the  sweep  phase,  if  this  has  not  already  been  done. 
Recall  that  this  might  have  occurred  if  power  had  been  removed  from  the  controller  at 
an  earlier  time,  whether  by  human  intervention  or  through  a  fault.  If  the  sweep  phase 
is  required,  the  function  do_y\veep()  is  called  to  do  it. 

Next  the  controller  must  decide  whether  or  not  a  launch  has  already  occurred. 
It  consults  the  launchdone  flag  in  page  0  of  the  bubble  memory.  If  this  flag  is  TRUE, 
the  Space  Shuttle  launched  earlier.  Othenvise,  we  must  listen  for  the  activation  of  the 
Auxiliary  Power  Units  (APUs)  by  calling  the  function  listenQ-  When  this  function 
completes  its  job,  it  will  return  a  mission  status.  This  can  take  on  any  one  of  the  fol¬ 
lowing  values: 

DAPUON  The  activation  of  the  APUs  has  been  detected. 
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DLAUNCH  The  activation  of  the  APUs  was  never  detected,  but  launch  was 

detected.  This  may  be  the  case  if  the  Vibration-activated 
Launch  Detector  detects  the  vibration  associated  with  the  ig¬ 
nition  of  the  solid  rocket  motors  or  if  the  Barometric  Pressure 
Switches  detect  an  ascent. 

DUSERNOAPU  The  system  is  being  tested  on  the  ground  and  the  user  depressed 
a  key  while  the  system  was  listening  for  the  APUs.  This  pro¬ 
vides  a  means  of  terminating  the  period  of  waiting  for  a  signal. 

If  listenO  detects  anything,  then  the  function  e.\pmnt()  will  turn  on  the  Analog- 
to-Digital  (A/D)  Converter  by  sending  the  code  ADON  to  the  function  poner_>vrite(). 
It  then  will  turn  on  the  Solid  State  Data  Recorder  (SSDR)  by  sending  the  code 
SSDRON  to  the  same  function.  Both  these  actions  will  be  logged  in  the  bubble  memoiy 
by  the  function  logeveiit().  If  listen()  had  returned  the  mission  status  code  D.APUON, 
then  expmiitO  commands  the  SSDR  to  enter  scroll  mode,  which  means  that  it  will  start 
recording  ambient  noise.  Since  the  APUs  are  now  on.  we  know  that  a  launch  must  oc¬ 
cur  within  seven  minutes,  or  the  mission  will  be  scrubbed  by  N.AS.A.  We  want  to  wait 
at  least  this  long.  To  be  on  the  conservative  side,  we  begin  a  ten  ntinute  time-out  period, 
during  which  we  wait  for  some  indication  of  a  launch.  The  function  ueJaunchedO  will 
return  the  mission  status  code  DLAUNCH  if  it  detects  such  an  indication.  Ihe  function 
look_ahead_discard()  checks  to  see  whether,  during  ground  testing,  the  user  has  depressed 
a  key  during  this  time-out  period.  If  so.  we  regard  the  time-out  as  having  been  com¬ 
pleted.  This  permits  accelerated  testing  of  the  system  without  always  waiting  for  the  end 
of  the  full  time-out  period.  Eventually  one  of  the  tw’o  conditions  will  have  occurred  and 
the  waiting  period  will  end. 

If  the  launch  had  occurred  at  some  earlier  time,  we  would  end  up  in  the  ne.xt 
section  of  the  code  in  e.xpmntQ-  The  fact  that  a  launch  had  occurred  previously  would 
be  logged  by  calling  logevent()  with  the  argument  PRIORLAUNCH,  and  the  mission 
status  would  be  set  to  this  same  value. 

The  next  section  of  code  is  executed  only  if  a  launch  is  in  progress.  The  SSDR 
is  commanded  to  leave  scroll  mode  and  enter  launch  mode.  The  SSDR  has  only  enough 
memory  to  record  two  minutes  of  noise  after  a  launch.  We  initiate  a  three-minute 
time-out  period  so  that  if  the  SSDR  fails  to  report  completion,  we  will  still  be  able  to 
go  on  to  other  tasks.  During  the  period  of  this  time-out,  we  want  to  ensure  that  a 
launch  is  recorded  in  page  0  of  the  bubble  memory,  if  in  fact  a  launch  has  occurred.  If 
the  launchdone  flag  in  page  0  has  not  been  made  TRUE  yet.  e.vpmtn()  calls 
baro_s>vitch().  This  funcion  will  check  the  condition  of  the  barometric  switches.  If  either 
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one  has  fired,  it  will  make  the  launchdone  flag  TRUE.  The  barometric  switches  are  re¬ 
garded  as  the  only  thoroughly  reliable  indication  of  a  launch. 

We  will  terminate  the  launch  phase  either  because  the  SSDR  reports  completion 
or  because  the  time-out  has  occurred.  We  record  whichever  of  these  is  the  case  by  call¬ 
ing  logeventO  with  either  the  argument  DOPCO.MP  or  DNOOPCO.MP,  respectively. 

Unless  expmntQ  detected  that  the  launch  had  been  aborted,  the  experiment  will 
next  invoke  the  function  postjaunchf).  This  function  will  keep  control  until  power  is 
removed  from  the  experimental  apparatus. 

B.  SUPPORTING  SUBROUTINES  AND  FUNCTIONS 

The  major  modules  of  the  control  program  were  described  in  Section  A.  Major 
Subroutines  and  Functions  on  page  108.  Subroutines  not  described  there  are  described 
here.  They  are  listed  alphabetically  by  the  name  of  the  source  file  in  which  they  are  de¬ 
fined,  and  alphabetically  by  function  name  within  file  name. 

1.  File  bubble.c 

a.  void  bpnge$et( int  page ) 

This  subroutine  initializes  the  parametric  registers  in  the  bubble  memor\‘. 
There  are  five  of  these,  and  they  contain  information  about  the  bubble  memory's  status 
and  about  upcoming  data  transfers.  The  meaning  of  the  fields  within  these  registers  is 
given  in  Table  11  on  page  122.  A  complete  description  of  their  use  is  given  in  [Ref  1: 
pp.  7-12],  from  which  the  information  in  Table  11  on  page  122  is  taken. 
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Table  11.  CONTENTS  OF  THE  PARAMETRIC  REGISTERS  IN  THE  BUBBLE 


MEMORY  CONTROLLER:  Extracted  from  [Ref.  1  :  Chapter  3,  pp. 
7-12L _ 


REGIS¬ 
TER  AD¬ 
DRESS 

REGISTER 

NAME 

BIT 

FIELD 

CONTENTS 

OxOb 

Least  Significant 
Byte  of  the  Block 
Length  Register 

0-7 

Least  significant  eight  bits  of  the 
block  length.  The  block  length 
is  the  number  of  pages  trans¬ 
ferred  to  or  from  the  bubble 
memory  at  one  time. 

0-2 

.VIost  significant  tliree  bits  of  the 
block  length.  Thus  there  are  1 1 
bits  in  the  block  length,  permit¬ 
ting  up  to  2"  =  204S  pages  to  be 
transferred  at  once. 

3 

Unused 

OxOc 

■Most  Significant 
Byte  of  the  Block 
Length  Register 

4-7 

The  number  of  Torniatter  Sense 
Amplifier  channels  available. 

The  binary  value  OOul  is  appro¬ 
priate  here  because  we  have  only 
one  bubble  memory  attached. 

Two  channels  are  used  to  com¬ 
municate  with  the  bubble  mem¬ 
ory.  With  a  single  bubble 
memory  available,  the  page  size 
is  defined  to  be  64  bytes  in 
length. 
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0 

Interrupt  enable  (normal).  We 
set  this  to  0  because  vve  are  not 
using  interrupts  to  communicate 
with  the  bubble  memory  control¬ 
ler. 

1 

Interrupt  enable  (error).  We  set 
this  to  0  because  we  are  not  using 
interrupts  to  communicate  with 
the  bubble  memory  controller. 

2 

Direct  Memory  Access  (DMA) 
Enable.  We  set  this  to  0  because 
we  are  not  using  DMA  with  the 
bubble  memory. 

3 

Reserved  by  Intel. 

OxOd 

Enable  Register 

4 

Write  Bootlooop  Enable.  The 
bootloop  is  used  internally  to  the 
bubble  memory.  It  need  never 
be  rewritten  except  as  part  of  a 
diagnostic  test.  We  let  this  be  0 
since  we  don't  want  to  modify  the 
bootloop. 

5 

Enable  Read  Corrected  Data 
(RCD).  We  set  this  to  1  to  per¬ 
mit  the  format  sense  amplifier  to 
apply  error  correction  to  errone¬ 
ous  data.  If  the  error  is  uncor- 
rectable.  then  the  erroneous  data 
will  be  transferred  to  the  host 
processor. 

6 

Enable  Internally  Corrected  Data 
(ICD).  Setting  this  causes  the 
bubble  memory  to  notify  the  host 
processor  of  its  inability  to  cor¬ 
rect  erroneous  data.  In  this  case, 
it  does  not  transfer  that  data. 

We  set  this  to  0  and  don't  use  the 
feature. 

7 

Enable  Parity  Interrupt.  We  set 
this  bit  to  0  because  we  are  not 
using  interrupts. 

OxOe 

The  Least  Signif¬ 
icant  Byte  of  the 
Address  Register 

0-7 

The  least  significant  byte  of  the 
address.  The  address  refers  to  the 
particular  page  within  the  bubble 
memory  w’here  data  transfers  are 
to  begin.  Since  we  are  using  a 
block  length  of  one  page,  this 
actually  addresses  the  single  page 
we  are  transferring. 
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OxOf 


Most  Significant 
Byte  of  the  Ad¬ 
dress  Register 


0-4 

.Viost  significant  five  bits  of  the 
address.  1  hus  there  are 

2'^  =  8192  pages  in  the  bubble 
memory. 

5-7 

Magnetic  Bubble  .Memory 
(MBM)  Select.  This  field"  con¬ 
trols  which  bubble  memory  is 
addressed.  Since  we  only  are  us¬ 
ing  one  bubble  memory,  we  set 
this  to  all  zeroes. 

b.  char  issububcmd( char  command) 

This  subroutine  is  used  to  issue  a  command  to  the  bubble  memory  con¬ 
troller  on  the  main  controller  circuit  board.  The  sequence  it  follows  is  given  in  detail  in 
[Ref  I:  pp.40-45].  For  our  purposes,  the  sequence  is  as  follows: 

1.  Make  sure  the  BUSY  bit  is  0  before  sending  any  command  (except  ABORT).  To 
do  this,  we  read  the  status  code  in  the  BL'BCTRL  port  and  check  the  BBUSY  bit. 
When  this  is  a  0,  we  can  proceed.  More  than  one  attempt  will  be  made  to  succeed 
in  this.  If  the  check  fails  repeatedly,  the  subroutine  displays  the  status  code  and 
returns  a  value  of  F.ALSE. 

2.  Issue  the  command  to  the  bubble  memory  controller  by  calling  the  function 
output(). 

3.  Check  to  see  that  the  command  was  accepted.  This  is  signalled  by  the  bubble  me¬ 
mory-  controller's  setting  the  BUSY  bit  once  again.  If  the  BUSY  bit  is  not  set 
within  a  reasonable  amount  of  time,  the  command  was  not  accepted.  In  the  case 
of  the  commands  FIFO  RESET  and  WRITE  BOOTLOOP  REGISTER,  we  can 
ignore  the  fact  that  the  BUSY  bit  never  was  set  if  we  get  an  OPElU-\TloSs'  COM¬ 
PLETE  anyway. 

4.  Wait  for  the  OPERATION  COMPLETE  code  from  the  bubble  memory  controller. 
If  this  does  not  occur  within  a  reasonable  time,  the  command  did  not  succeed. 

The  phrase  “a  reasonable  time”  in  this  subroutine  means  that  the  bubble  memory 
controller’s  status  was  inspected  BTRIES  times  without  success.  We  have  written  the 
subroutines  such  that  they  will  regard  the  command  as  having  been  successful  if  the 
bubble  memory  controller  returns  an  OPERATION  COMPLETE  code  even  if  the 
BUSY  bit  remains  0.  ([Ref  1]  does  not  suggest  that  this  latter  indication  can  occur. 
However,  if  the  command  is  accepted  and  completed  very  quickly,  the  control  program 
might  never  observe  the  BBUSY  bit,  so  it  seems  to  be  a  good  idea  to  permit  it.) 

It  was  our  intention  that  this  subroutine  be  used  to  issue  all  commands  to 
the  bubble  memory.  However,  it  executed  too  slowly  to  permit  its  use  with  data  trans¬ 
fers.  The  subroutines  bubread()  and  bub>vrite(),  written  in  assembly  language,  were 
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written  for  this  purpose.  In  the  case  of  other  commands,  TRUE  is  only  returned  if  the 
bubble  memor\-  returns  OPERATION  COMPLETE  in  the  status  byte.  FALSE  is  re¬ 
turned  otherwise. 

2.  File  bubrw.s 

a.  char  bubxfer(  void) 

This  subroutine  is  required  during  initialization  of  the  bubble  memory.  It 
writes  40  OxIT  characters  to  the  bubble  memory.  It  returns  TRUE  if  the  transfer  w'orked; 
FALSE  otherwise.  The  subroutine  is  written  in  assembly  language  for  speed,  but  is 
called  in  the  same  manner  as  a  C  subroutine. 

b.  char  bubread(  char  *  buffer) 

This  subroutine  reads  data  from  the  bubble  memory  and  places  it  in  a  buffer 
whose  address  is  passed  as  a  parameter.  It  is  written  in  assembly  language  in  order  to 
execute  sufTiciently  rapidly  to  preclude  overflowing  the  buffer  in  the  Bubble  Memory 
Controller  (BMC).  The  listing  of  this  subroutine  includes  many  comments  which  explain 
the  purpose  of  each  step.  The  following  is  a  list  of  the  actions  which  must  be  accom¬ 
plished  by  this  subroutine. 

1.  Save  the  contents  of  all  registers. 

2.  Issue  the  FIFO  reset  command  to  the  BMC. 

3.  Issue  the  READ  command  to  the  BMC. 

4.  Wait  for  the  BUSY  bit  to  become  a  one.  If  this  never  happens,  the  command  has 
failed. 

5.  Input  64  characters  from  the  bubble  memory.  The  FIFO  bit  must  be  set  to  I  be¬ 
fore  each  character  is  read.  If  this  bit  never  becomes  a  1,  the  command  has  failed. 

6.  Restore  the  contents  of  all  registers  to  w^hat  they  w'ere  before  the  subroutine  began 
to  execute. 

c.  char  bubwrite(  char  *  buffer) 

This  subroutine  writes  data  to  the  bubble  memory  from  a  buffer  whose  ad¬ 
dress  is  passed  as  a  parameter.  It  is  written  in  assembly  language  in  order  to  execute 
sufiiciently  rapidly  to  preclude  having  the  Bubble  .Memory  Controller  (BMC)  empty  its 
internal  buffer  before  all  the  data  has  been  sent  to  it  by  the  experiment  controller.  The 
listing  of  this  subroutine  includes  many  comments  which  explain  the  purpose  of  each 
step.  The  following  is  a  list  of  the  actions  which  must  be  accomplished  by  this  subrou¬ 
tine. 

1.  Save  the  contents  of  all  registers. 

2.  Issue  the  FIFO  reset  command  to  the  BMC. 
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3.  Issue  the  WRITE  command  to  the  BMC. 

4.  Wait  for  the  BUSY  bit  to  become  a  one.  If  this  never  happens,  the  command  has 
failed. 

5.  Output  64  characters  to  the  bubble  memory.  The  FIFO  bit  must  be  set  to  1  before 
each  character  is  written.  If  this  bit  never  becomes  a  1,  the  command  has  failed. 

6.  Restore  the  contents  of  all  registers  to  what  they  were  before  the  subroutine  began 
to  execute. 

3.  File  clock.c 

a.  void  clockintf  struct  datetime  *  clock,  struct  idatetime  *iclock) 

This  subroutine  takes  a  datetime  structure  pointed  to  by  clock  and  converts 
it  to  an  idatetime  structure  pointed  to  by  iciock.  The  function  bcd_int()  is  used  to  convert 
the  binary’  coded  decimal  (BCD)  format  used  in  the  datetime  structure  into  the  integer 
format  used  in  the  idatetime  structure. 

b.  char  clockcompare(  struct  idatetime  *clockl,  struct  idatetime  *  clock!) 

This  subroutine  compares  the  two  times  pointed  to  by  clock  1  and  clock2. 
It  will  return  TRUE  if  the  first  time  is  equal  to  or  later  than  the  second;  FALSE  other¬ 
wise.  To  do  the  comparison,  each  element  of  the  time  is  compared,  from  month  down 
to  second,  in  that  order.  The  principle  difilculty  is  in  comparing  dates  that  span  New 
^'ear’s  Day.  We  want  January  1  to  be  regarded  as  coming  after  December  31.  not  be¬ 
fore. 

To  do  this  we  first  subtract  the  second  month  from  the  first.  The  difference 
is  taken  modulo  12.  The  modulo  operation  would  not  change  any  difference  from  0 
through  11;  a  difference  of  —II  through  —I  would  be  changed  to  1  through  11  respec¬ 
tively.  Results  in  the  range  1  through  5  indicate  that  the  first  date  is  later  than  the  sec¬ 
ond. 

For  example,  if  the  first  date  is  January  (month  1)  and  the  second  date  is 
December  (month  12),  the  difference  is  1  —  12  =  —11.  When  this  is  taken  modulo  12, 
we  get  1.  Thus  January  is  1  month  after  December. 

If  the  first  date  is  June  (month  6)  and  the  second  date  is  December  (month 
12),  the  difierence  is  6  —  12  =  —6.  Taken  modulo  12,  this  is  6.  Since  this  is  greater  than 
5,  we  regard  June  as  coming  before  December,  not  after. 

c.  void  clocksum( struct  idatetime  ^result,  struct  idatetime  ^clockl,  struct 
idatetime  *clock2) 

This  subroutine  adds  together  the  date  and  time  pointed  to  by  the  idatetime 
structure  clockl  to  the  number  of  months,  days,  etc.  in  the  idatetime  structure  pointed 


126 


to  by  clock2,  yielding  a  new  idatetime  structure  pointed  to  by  result.  This  is  useful  when 
from  a  given  date  and  time  one  wishes  to  calculate  a  later  date  and  time.  The  usual  use 
of  this  subroutine  is,  given  the  current  date  and  time,  to  calculate  the  date  and  time  after 
some  given  delay  has  elapsed.2S 

It  starts  by  adding  the  seconds  together,  and  works  from  there  up  to  the 
months.  After  each  addition,  checks  are  made  to  ensure  that  the  result  is  valid.  If  not 
{e.g.,  63  minutes  is  not  valid),  the  result  is  corrected  and  any  excess  is  carried  over  to  the 
next  highest  unit  of  time. 

The  fact  that  diflerent  months  have  different  lengths  is  a  bit  of  a  nuisance 
which  is  overcome  by  considering  the  three  possible  cases:  a  month  can  have  3 1  days, 
30  days  or  28  days.  Leap  years  are  ignored,  since  the  real-time  clock  does  not  store  the 
current  year,  and  so  is  unaware  of  leap  years. 

d.  void  show  _waketime(  struct  idatetime  *  waketime) 

This  function  displays  the  date  and  time  stored  in  the  idatetime  structure 
pointed  to  by  \vaketime  on  the  terminal. 

e.  void  dump  Jiclock(  struct  idatetime  *  clock) 

This  subroutine  displays  the  date  and  time  (when  stored  in  integer  format) 
on  the  terminal. 

/.  void  getjimef  struct  idatetime  *  clock  ) 

This  subroutine  asks  the  user  for  the  date  and  time.  Each  response  is 
checked  for  correctness  to  preclude  invalid  dates  and  times  being  entered.  The  function 
getintO  is  used  to  get  the  responses  from  the  keyboard.  The  responses  are  converted  to 
binar}-coded  decimal  (BCD)  format  and  stored  in  the  structure  whose  address  is  passed 
as  a  parameter  to  the  function. 

g.  void  show _waketime( struct  idatetime  *waketime) 

This  subroutine  displays  on  the  terminal  the  date  and  time  when  a  time-out 
will  have  been  completed.  The  date  and  time  are  provided  in  the  structure  whose  address 
is  passed  as  a  parameter. 

h.  char  timeout  ( int  delay  time,  int  measure) 

This  subroutine  has  two  purposes: 

1.  It  initiates  a  time-out  sequence. 

2.  It  checks  to  see  whether  a  time-out  sequence  has  been  completed  yet.  This  is  the 
case  when  the  wake-up  time  calculated  presiously  has  been  reached. 

25  While  it  could  be  used  to  add  two  dates  together,  this  would  not  be  particularly  meaningful. 
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The  subroutine  calls  the  function  allow_ctrl_interrupts()  to  permit  its  being 
interrupted  during  ground  testing  by  the  depression  of  a  key  on  the  terminal.  It  then 
calls  clockreadO  to  get  the  current  date  and  time.  This  is  converted  to  integer  format 
by  a  call  to  clockint().  If  the  parameter  deiayiime  is  the  constant  NULL,  then  the 
function’s  purpose  is  to  see  whether  a  time-out  set  previously  has  expired.  The  function 
clockcompare()  is  invoked  to  compare  the  stored  date  and  time  with  the  current  date  and 
time.  Its  result  is  returned  as  the  result  of  timeout(). 

If  the  parameter  delajlime  is  not  the  constant  NULL,  then  the  function’s 
purpose  is  to  initiate  a  time-out  sequence.  The  structure  waittime  is  initialized  to  zero. 
One  of  its  elements  is  then  modified  to  contain  the  number  of  delay  units  passed  as  the 
parameter  dela\1ime.  Which  element  is  modified  is  determined  by  the  parameter 
measure,  which  can  take  on  the  values  MONTH,  D.ATE.  HOURS.  MINUTES,  or 
SECONDS.  The  subroutine  ciocksum()  is  called  to  add  together  the  current  time  and 
the  amount  of  time  to  wait.  The  result  is  displayed  by  calling  the  function 
show_waketime().  The  wake-up  time  is  stored  in  a  global  structure,  waketime,  so  its 
contents  will  be  undisturbed  the  next  time  this  function  is  called. 

4.  File  coiivert.c 

a.  char  atoh(  char  *  ascii) 

This  function  converts  the  two-character  hexadecimal  string  pointed  to  by 
ascii  and  converts  it  to  a  single  character.26  if  the  characters  in  ascii  are  in  the  range  ‘0’ 
through  ‘9’  or  ‘a’  through  T,  then  they  will  be  properly  interpreted  as  hexadecimal  digits. 
Capital  letters  (‘A’  through  ‘F’)  and  any  other  characters  are  treated  as  zeros.  For  ex¬ 
ample,  the  character  string  “63”  would  be  converted  to  the  single  character  ‘c’.  since  the 
hexadecimal  representation  of  this  ASCII  character  is  0x63. 

b.  unsigned  inf  atohexintf  char  ascii[  ] ) 

This  subroutine  converts  a  four-byte  ASCII  string  of  characters  which  rep¬ 
resent  a  valid  hexadecimal  word  into  a  single  unsigned  integer.  No  checks  are  made  to 
see  that  the  character  string  is  valid,  but  invalid  characters  are  sufficient  to  cause  the 
subroutine  to  stop  processing  the  character  string.  If  no  valid  string  of  hexadecimal 
characters  is  found,  the  value  0  is  returned  by  this  subroutine. 

c.  int  atoi( char  *s  ) 

This  function  converts  a  four-character  string  to  an  integer.  The  string  may 
optionally  include  a  sign  (+  or  -)  in  the  first  position.  Successive  characters  will  be 

26  No  check  is  made  to  ensure  that  ascii  is  only  two  characters  in  length. 
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converted  to  numeric  values  if  they  are  in  the  range  ‘0’  through  ‘9'.  Conversion  ceases 
as  soon  as  a  character  fails  to  fall  within  this  range.  No  checking  is  done  to  ensure  that 
the  number  of  digits  provided  can  fit  within  the  number  of  bytes  reserved  for  integers. 
This  subroutine  is  from  Bilofsky  [Ref.  18). 

d.  char  *bcdjisc( char  bed) 

This  function  converts  a  binary  coded  decimal  (BCD)  character  into  an 
ASCII  string.  For  e.xample,  the  single  byte  0x63  is  converted  to  a  two-character  string 
“63”.  The  BCD  character  is  first  converted  to  an  integer.  It  is  assumed  that  an  integer 
occupies  two  bytes.  If  the  leading  nibble  of  the  character  is  a  0,  it  will  be  converted  to 
a  space  (‘  ').  No  check  is  made  to  see  if  the  BCD  character  is  valid.  The  function  returns 
a  pointer  to  the  .ASCII  string  representation. 

Since  it  always  uses  the  same  storage  location  to  hold  the  converted  result, 
the  string  should  be  copied  to  another  variable  before  bcd_ascii()  is  called  again,  for  the 
old  contents  will  be  destroyed. 

e.  int  bcdjntf  char  bed ) 

This  function  converts  a  binary  coded  decimal  (BCD)  character  into  an  in¬ 
teger.  No  checking  is  done  to  ensure  the  BCD  character  is  valid.  The  integer  result  is 
returned. 

/.  char  *ctoh  ( char  byte ) 

This  function  converts  a  character  byte  into  a  hexadecimal  string  represen¬ 
tation.  It  returns  a  pointer  to  the  string.  Since  it  always  uses  the  same  storage  location 
to  hold  the  converted  result,  the  string  should  be  copied  to  another  variable  before  ctoh() 
is  called  again,  for  the  old  contents  will  be  destroyed. 

g.  char  int _bcd( int  decimal) 

This  function  converts  an  integer  into  BCD  format.  It  will  handle  positive 
integers  in  the  range  0  through  99.  No  checking  is  done  to  ensure  the  integer  falls  within 
this  range.  The  function  returns  the  BCD  result  as  a  single  character. 

h.  char  *itoa( int  n,  charf  ] ) 

This  function  converts  an  integer  n  into  an  ASCII  representation.  It  con¬ 
verts  the  integer  into  digits  by  taking  it  modulo  10  and  storing  the  digits  in  character 
form  in  reverse  order.  Upon  completion,  it  reverses  the  string  in  place.  The  result  is 
stored  in  the  location  pointed  to  by  the  parameter  s.  No  check  is  made  to  ensure  this 
location  has  enough  storage.  This  is  the  user's  responsibility.  However,  in  a  machine 
with  two-byte  integers,  the  largest  possible  integer  will  contain  five  digits.  The  user 
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should  allow  two  extra  locations  for  the  sign  and  the  terminating  NULL  character,  or 
seven  characters  in  ail.  This  subroutine  is  from  Bilofsky  [Ref  18]. 

I.  char  tolower(int  c) 

This  function  converts  upper  case  alphabetic  characters  into  lower  case 
ones.  This  subroutine  is  from  Bilofsky  [Ref.  18).  Its  use  here  is  a  consequence  of  our 
having  used  this  C  compiler  during  the  early  work  on  this  project.  This  function  is 
provided  in  the  librarj’  supplied  with  the  L'niware  C  Compiler;  with  the  Toolworks  C 
Compiler,  its  source  code  had  to  be  included  with  our  source  code.  It  could  have  been 
removed  when  we  switched  over  to  using  the  Uniware  C  Compiler,  but  it  never  was. 
There  exist  other  vestiges  of  our  early  use  of  the  Toolworks  C  Compiler  that  have  never 
been  eradicated. 

j.  char  * uitoh( unsigned  int  word) 

This  subroutine  converts  an  unsigned  integer  to  hexadecimal  ASCII  string 
format.  For  example,  the  unsigned  integer  ‘28’  is  converted  to  the  character  string 
“1C"  since  that  is  its  ASCII  representation. 

5.  File  delay.s 

a.  void  delay  ( int  n ) 

This  function  provides  a  timing  delay  of  n  x  10  ms  .  It  is  written  in  Z-80 
assembly  language.  It  will  only  work  correctly  if  the  system  clock  has  frequency  f  =  2.5 
MHz.  It  is  adapted  from  a  program  written  by  Mr.  David  Rigmaiden  of  the  Naval 
Postgraduate  School. 

6.  File  expmnt.c 

o.  char  ad_read( char  port ) 

This  subroutine  will  obtain  one  character  from  that  channel  of  the  Ana- 
log-to-digital  (A  D)  Converter  whose  address  is  pass  as  the  parameter  port.  It  functions 
by  writing  anything  at  all  to  that  port  address  (we  chose  arbitrarily  to  send  a  0),  then 
by  waiting  for  one  10  ms  period  during  which  the  A,'D  converter  responds,  and  then  fi¬ 
nally  by  reading  a  character  from  the  same  port.  This  is  the  character  returned  by  the 
subroutine. 

b.  int  adtoint( char  addata,  unsigned  long  multiplier) 

The  purpose  of  this  subroutine  is  to  convert  a  character  input  from  the 
Analog-to-digital  (A/D)  Converter  into  an  integer  which  represents  the  measured  quan¬ 
tity  in  more  meaningful  units  than  an  arbitrary  number  in  the  range  [0,255],  which  is  all 
that  the  A,  D  converter  can  provide.  It  would  be  natural  to  perform  the  arithmetic 
scaling  of  the  input  eight-bit  number  addata  to  the  corresponding  output  value  by  per- 
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forming  ordinary^  floating-point  multiplication  and  division.  This  has  one  drawback  in 
a  microprocessor  application:  the  executable  code  to  support  floating  point  operations 
takes  up  rather  a  large  amount  of  memor^^  In  tests  we  performed  using  the  floating 
point  arithmetic  operators  provided  with  the  Uniware  C  Compiler,  the  subroutines  re¬ 
quired  two  extra  EPROMS  of  8  KBytes  apiece.  VVe  had  the  room  in  our  controller  to 
accept  this,  but  chose  not  to  do  so  since  our  need  for  floating  point  arithmetic  was  lim¬ 
ited  to  this  one  function.  To  program  two  complete  EPROMS  every  time  a  new  version 
of  the  program  was  compiled  solely  to  provide  this  one  use  of  floating  point  of  arith¬ 
metic  was  not  warranted,  in  our  judgement. 

The  alternative  was  to  perform  the  scaling  operation  with  fixed  point  arith¬ 
metic.  The  C  programming  language  supports  integer  operations,  but  fixed  point  oper¬ 
ations  with  a  movable  decimal  point  are  not  supported.  This  subroutine  uses  an  implied 
decimal  point.  As  far  as  the  subroutine  is  concerned,  the  operands  are  integers,  plain 
and  simple.  By  using  unsigned  long  integers,  we  have  32  bits  of  accuracy,  permitting 
numbers  in  the  range  [0,4.294967296  x  lO’).  For  our  purposes,  we  have  have  used  a  di¬ 
visor  of  10‘.  This  has  the  effect  of  reducing  the  range  of  useful  numbers  to  [0.4294] . 

The  purpose  of  these  manipulations  is  to  permit  all  the  accuracy  promised 
by  the  provision  of  eight  bits  from  the  A  D  converter  while  avoiding  floating  point 
arithmetic.  The  details  of  the  operation  are  included  as  comments  in  the  program  listing, 
so  will  not  be  repeated  here. 

c.  void  alter _page0( struct  pageOdata  *  pagezero) 

This  subroutine  permits  the  user  to  alter  the  flags  stored  in  page  0  of  the 
bubble  memory.  Since  these  flags  describe  the  current  status  of  the  experiment,  and  also 
indicate  which  area  of  the  bubble  memory  is  available  for  use,  their  alteration  amounts 
to  initializing  the  status  of  the  experiment  to  a  known  value.  The  use  of  this  subroutine 
is  described  in  Chapter  V.  HOW  TO  GET  THE  EXPERI.MENT  READY  FOR  A 
LAUNCH  on  page  63.  It  displays  a  menu  using  the  same  method  used  in  so  many  other 
functions  in  the  control  program.  This  method  was  already  presented  in  the  description 
of  the  function  mainQ.  A  while  loop  presents  the  menu  repeatedly  until  choice  Z  is 
made.  The  menu  shows  the  current  values  of  all  the  information  stored  in  page  0  of  the 
bubble  memory.  In  most  cases  it  also  shows  the  other  possible  value  of  each  flag.  The 
sole  exceptions  are  the  value  of  the  next  available  page,  which  can  fall  in  the  range 
[1,8191],  and  the  flag  RECORD_start_time,  which  is  a  date  and  time. 

If  any  of  the  values  is  changed,  page  0  is  rewritten. 
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d.  char  bad_idea_to_record( char  show ) 

In  the  abridged  experiment,  the  only  phase  of  the  experiment  is  record.  It 
would  be  unfortunate  if  the  Solid  State  Data  Recorder  were  restarted  in  record  mode 
after  the  launch  had  already  occurred,  for  this  would  erase  the  recording  of  the  launch 
and  replace  it  with  the  silence  that  fills  the  cargo  bay  in  space,  or  possibly  all  the  sounds 
of  the  launch  except  the  moment  of  ignition  of  the  solid  rocket  motors.  How  could  this 
happen?  A  power  fault,  for  whatever  reason,  would  cause  the  controller  to  start  at  the 
beginning  upon  the  restoration  of  power.  There  is  no  obvious  way  for  the  controller  to 
be  sure  that  it  is  still  on  the  ground,  which  certainly  is  the  only  time  when  it  is  really  a 
good  idea  to  initiate  the  record  phase.  Of  course,  it  is  easy  to  determine  whether  it  is  in 
space  or  not  simply  by  checking  the  status  of  the  barometric  pressure  switches.  Our 
solution  is  simply  to  prohibit  the  initiation  of  record  mode  more  than  once  in  12  hours. 
If  a  mission  is  scrubbed,  it  will  be  at  least  2-1  hours  before  it  is  rescheduled.  The  12  hour 
delay  will  have  elapsed  by  this  time,  and  the  abridged  experiment  could  then  be  per¬ 
formed  as  planned. 

The  long  and  the  short  of  these  considerations  is  that  this  function  com¬ 
pares  the  current  time  to  the  time  when  record  was  last  initiated.  This  time  is  stored  in 
page  0  of  the  bubble  memor>-.  If  insufficient  time  has  elapsed,  the  function  returns  the 
value  TRUE,  meaning  that  it  is  a  bad  idea  to  record.  If  12  hours  has  elapsed,  it  returns 
the  value  F.^LSE,  meaning  it  is  not  a  bad  idea  to  record;  record  mode  can  be  initiated, 
in  this  case. 

e.  void  display _pageO( struct  pageOdata  *  pagezero) 

This  subroutine  displays  the  contents  of  page  0  of  the  bubble  memor>'  on 

the  terminal. 

f.  void  do_sweep(void) 

This  function  performs  the  sweep  phase  of  the  unabridged  experiment.  It 
turns  on  (and  logs  the  fact  that  it  has  done  so)  the  Analog-to-digital  (A  D)  Converter 
and  the  Solid  State  Data  Recorder  (SSDR).  It  then  commands  the  SSDR  to  enter  sweep 
mode.  After  a  10  second  time-out,  it  applies  power  to  the  Voltage  Controlled  Oscillator 
(VCO)  which  is  responsible  for  filling  the  Space  Shuttle  cargo  bay  with  sounds  of  known 
frequency. 

Next  it  initiates  a  13  minute  time-out.  The  SSDR  should  signal  completion 
of  the  sweep  phase  before  this  much  time  has  elapsed.  If  this  does  not  happen,  the 
time-out  allows  the  control  program  to  stop  waiting  for  it  to  do  so.  Upon  completion 
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of  the  sweep  phase,  the  do_s>veep()  phase  removes  power  from  the  VCO,  SSDR,  and  A  D 
converters. 

g.  char  initialize( void) 

This  subroutine  extracts  the  status  information  from  page  0  of  the  bubble 
memory  when  the  expmntQ  program  begins  to  execute.  It  will  remove  power  from  the 
Voltage  Controlled  Oscillator  (VCO),  which  performs  the  sweep  phase,  and  from  the 
heater  subsystem,  if  either  of  these  is  on.  It  will  not  remove  power  from  the  other  sub¬ 
systems,  which  also  might  be  on  when  power  is  first  applied.  How  can  this  be,  and  why 
does  it  not  remove  power  from  them?  One  way  in  which  power  might  be  applied  is  after 
a  brief  power  fault.  If  the  fault  affected  the  controller  but  not,  say,  the  Solid  State  Data 
Recorder  (SSDR),  and  if  sweep  mode  had  been  initiated  prior  to  the  loss  of  power,  re¬ 
moving  power  from  the  SSDR  would  have  the  effect  of  terminating  sweep  mode  and  this 
would  raise  the  possibility  that  an  otherwise  successful  recording  of  the  ignition  of  the 
solid  rocket  motors  would  be  foiled.  The  SSDR  and  other  subsystems,  therefore,  should 
not  be  interfered  with  at  this  point. 

h.  char  lhten(  void) 

This  subroutine  applies  power  to  the  matched  filter  circuit  board.  It  then 
calls  >vejaunched().  This  function  returns  DLAUNCH  if  a  launch  has  occurred,  and  this 
value  is  returned  by  listen(),  too.  If  a  launch  has  not  yet  occurred,  listen()  checks  to  see 
if  the  matched  filter  has  detected  the  starting  of  the  Auxiliary  Power  Units  (.APUs).  If 
so,  the  function  returns  the  value  DAPUON.  If  neither  condition  has  occurred,  the 
function  calls  the  subroutine  look_ahead_discard(),  giving  the  user  (if  any)  to  get  out  of 
the  listenO  function  by  depressing  any  key  on  the  terminal.  Barring  one  of  these  three 
conditions,  the  function  will  continue  making  these  same  checks  indefinitely. 

I.  char  logevent( char  event) 

This  subroutine  makes  coded  entries  in  the  bubble  memory  of  all  events 
which  take  place.  While  it  is  doing  this,  it  takes  readings  from  each  of  the  channels  of 
the  Analog-to-digital  (A  D)  Converter  and  stores  the  results  in  the  same  page  of  the 
bubble  memory  in  which  the  event  code  is  stored.  If  the  bubble  memory  is  already  full, 
which  would  occur  after  2  x  8191  *  16,382  events,  the  subroutine  refuses  to  store  any 
more  events.  This  will  preclude  the  destruction  of  the  records  of  earlier  events.  How¬ 
ever,  we  do  not  expect  this  many  events  ever  to  occur  on  a  single  mission  of  the  Space 
Shuttle.  The  interval  between  successive  events  after  the  first  two  minutes  of  flight  is  five 
minutes;  at  this  rate,  it  would  take  nearly  57  days  to  fill  up  the  memory. 
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There  are  two  possibilities  when  the  function  prepares  to  write  a  page  of 
information  to  the  bubble  memor>’.  Either  this  is  a  brand  new  page,  or  it  is  the  second 
half  on  an  existing  page  of  stored  data.  In  the  former  case,  the  second  half  of  the  page 
is  filled  with  NULL  characters.  This  effectively  erases  any  data  previously  stored  in  this 
upper  half-page.  The  subroutine  next  reads  the  current  date  and  time  and  stores  this  in 
the  structure  w'here  all  the  information  is  assembled  prior  to  being  transferred  to  the 
bubble  memory^  The  event  code  is  passed  to  the  function  logevent()  as  parameter  event 
to  be  stored  in  the  bubble  memory.  Each  channel  of  the  A  D  converter  is  sampled  and 
the  results  also  are  stored  in  the  bubble  memory.  If  the  event  code  is  CSSWEEP,  then 
the  command  to  initiate  ^weep  mode  has  just  been  issued,  and  the  flag  sweepstarted  in 
page  0  needs  to  be  set  to  TRUE.  If  the  event  code  is  DPRESSURE,  then  the  flag 
launchdone  in  page  0  needs  to  be  set  to  TRUE.  Then  the  new  record  of  information  can 
be  written  to  the  next  available  half  of  the  ne.xt  available  full  page  of  the  bubble  memoiy. 
The  page  number  and  half  page  number  are  extracted  from  page  0  of  the  bubble  mem¬ 
ory.  Page  0  needs  to  be  updated,  and  this  is  done  also. 

j.  void  logjnenu(  void) 

This  subroutine  provides  the  user  with  a  menu  for  changing  the  contents 
of  page  0  of  the  bubble  memory.  Recall  that  this  information  describes  the  current  sta¬ 
tus  of  the  experiment.  It  is  important  that  this  information  be  initialized  correctly  prior 
to  the  launch  of  the  Space  Shuttle.  How  to  do  this  is  described  in  Chapter  V.  HOW 
TO  GET  THE  EXPERIMENT  READY  FOR  A  LAUNCH  on  page  63. 

The  details  of  how  the  menu  is  generated  are  the  same  as  explained  in  the 
description  of  the  function  menuf)  and  will  not  be  repeated  here. 

k.  void  monitor  Jieaters( void) 

This  subroutine  has  the  job  of  maintaining  the  temperature  of  the  bubble 
memory  at  a  sufficiently  high  level  that  it  can  be  operated  safely.  If  it  finds  that  the 
current  temperature  is  low^er  than  the  minimum  desirable  temperature  (12'C)  it  will  turn 
the  heaters  on.  If  it  finds  that  the  temperature  is  above  the  maximum  desirable  tem¬ 
perature  (M^C),  it  will  turn  the  heaters  off.  This  is  not  the  temperature  above  w’hich  the 
bubble  memories  will  lose  their  memory.  Rather  it  is  a  temperature  chosen  to  be  slightly 
higher  than  the  minimum  desirable  temperature.  If  the  temperature  can  attain  this  level, 
the  heaters  will  be  shut  off  for  a  while  to  save  power.  If  the  temperature  falls  to  the 
minimum  desirable  level,  this  still  is  2'’C  above  the  minimum  operating  temperature,  al¬ 
lowing  a  reasonable  margin  for  safe  operation.  The  2'’C  spread  is  wide  enough  to  pre¬ 
clude  excessively  frequent  operation  of  the  relay  sw  itches,  too. 
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/.  void  postJaunch(  void) 

This  subroutine  performs  the  caretaking  functions  that  follow  the  successful 
launch  of  the  Space  Shuttle.  Its  first  action  is  to  remove  power  from  all  subsystems. 
It  then  initiates  a  five  minute  time-out.  During  this  w'ait,  it  calls  monitor_heaters()  re¬ 
peatedly  to  give  them  an  operation  to  operate  the  heater  subsjstem.  It  also  checks  the 
barometric  pressure  switches  if  they  have  not  yet  reported  a  completed  launch.  During 
ground  testing  it  is  useful  to  have  a  way  of  interrupting  this  phase  of  the  mission. 
Calling  look_ahead_discard()  lets  the  user  do  so  by  pressing  any  key  on  the  terminal. 
At  the  completion  of  the  five  minute  delay,  logeventQ  is  called  to  record  a  “read  A,  D” 
event.  The  function  logeventQ  takes  care  of  reading  all  the  Analog-to-digital  Converter 
(A  D)  channels  whenver  it  is  called.  Finally,  a  call  to  voltagesJowQ  is  made  to  ensure 
that  if  the  voltages  on  the  lOV  power  busses  falls  to  too  low  a  level,  the  experiment  will 
be  terminated.  This  will  preclude  an  attempt  to  operate  the  bubble  memories  with  in¬ 
sufficient  current,  which  could  cause  them  to  lose  their  contents. 

m.  void  record)  void) 

This  subroutine  performs  the  record  phase  of  the  abridged  experiment.  The 
first  action  taken  by  this  subroutine  is  to  read  the  current  date  and  time  and  to  place  this 
information  in  the  structure  of  data  to  be  stored  in  page  0  of  the  bubble  memorv’.  A  call 
to  logeventQ  immediately  after  this  has  the  effect  of  ensuring  that  this  date  and  time  are 
transferred  to  page  0  right  away,  along  with  taking  current  readings  of  all  the  channels 
of  the  Analog-to-digital  (A.'D)  Converter. 

The  recordQ  subroutine  then  applies  power  to  the  A  D  converters  and  the 
Solid  State  Data  Recorder  (SSDR),  commands  the  SSDR  to  enter  record  mode,  and  in¬ 
itiates  a  20  minute  time- _  The  SSDR  should  report  completion  of  record  mode  prior 

to  the  expiration  of  this  delay,  but  even  if  it  fails  to  do  so,  the  subroutine  will  be  able  to 
terminate  the  record  phase  of  the  experiment.  While  waiting  for  the  20  minutes  to 
elapse,  the  subroutine  calls  baro_switchQ  if  that  function  has  not  previously  reported  a 
successful  launch.  Upon  the  completion  of  the  record  phase,  the  subroutine  removes 
power  from  both  the  SSDR  and  the  A  D  converter. 

n.  void  short jexperiment) void) 

This  subroutine  performs  the  abridged  experiment.  It  first  checks  to  see 
whether  a  launch  had  occurred  previously.  This  could  be  the  case  if  a  power  fault  had 
caused  the  controller  to  start  executing  its  program  from  the  beginning.  If  a  launch  has 
been  recorded  already,  the  subroutine  refuses  to  put  the  Solid  State  Data  Recorder 


135 


(SSDR)  into  record  mode.  This  will  prevent  the  successful  recording  of  a  launch  to  be 
wiped  out. 

If  a  launch  has  not  occurred  previously,  then  the  subroutine  will  wait  until 
it  is  alright  to  initiate  record  mode.  This  is  indicated  by  the  subroutine 
badJdea_to_recordO  returning  the  value  FALSE,  meaning  it  is  not  a  bad  idea  to  start 
record  phase.  Next  the  subroutine  will  call  listenQ  to  listen  for  the  starting  of  the  Aux¬ 
iliary  Power  Units  (APUs).  The  listenQ  subroutine  will  keep  control  until  either  the 
APUs  start,  or  until  some  indication  of  a  launch  is  detected.  At  this  point,  the  record 
phase  is  initiated. 

It  is  conceivable  that  at  the  end  of  the  record  phase,  we  would  discover  that 
we  had  jumped  the  gun  and  that  the  Space  Shuttle  was  still  on  the  ground.  To  see 
whether  or  not  this  is  the  case,  the  subroutine  calls  baro_switch().  if  that  subroutine  had 
not  previously  reported  that  launch  had  definitely  been  completed.  If  no  launch  has 
occurred,  we  are  in  a  bit  of  a  quandary.  Is  launch  imminent?  How  long  will  it  be  before 
it  occurs?  It  would  be  nice  simply  to  re-initiate  record  mode,  but  this  consumes  consid¬ 
erable  power.  What  is  potentially  worse,  the  power  fault  might  occur  at  the  moment 
of  launch.  It  will  still  be  several  moments  before  the  barometric  switches  indicate  that 
a  launch  has  occurred.  Since  we  cannot  ascertain  whether  the  launch  has  occurred  or 
not,  it  is  best  to  assume  that  it  has  and  not  to  re-initiate  record  phase,  which  would  erase 
the  recording  of  the  launch.  So  we  have  adopted  the  solution  of  waiting  until  at  least 
12  hours  more  have  elapsed  before  entering  the  record  phase  again. 

At  the  successul  completion  both  of  record  phase  and  a  launch,  the 
short_e.\periment()  subroutine  calls  post_Iaunch()  to  perform  all  the  caretaking  functions 
required  during  the  Space  Shuttle’s  mission. 

0.  void  show jeventf  char  event) 

This  function  is  used  to  display  event  codes  stored  in  the  bubble  memorv’  log 
in  a  readable  form  on  the  display  terminal.  It  does  this  by  displaying  the  appropriate 
character  string  from  an  array  of  strings  which  describe  the  various  codes. 

p.  void  shutjdown( void) 

This  function  removes  power  from  any  subsystem  which  currently  is  re¬ 
ceiving  power.  It  calls  logeventQ  to  record  any  actions  it  takes. 

q.  char  ssdrmode(char  mode) 

This  subroutine  issues  commands  to  the  Solid  State  Data  Recorder  (SSDR). 
If  the  command  is  unsuccessful  the  first  time,  it  will  make  several  more  tries  before  giv¬ 
ing  up.  Once  the  command  has  been  issued,  the  subroutine  waits  for  20  ms  and  then  it 
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checks  the  status  code  returned  by  the  function  ssdr_status().  The  desired  response  from 
the  SSDR  is  that  the  commanded  operation  has  been  completed  successfully,  which  is 
indicated  by  the  return  of  the  constant  NORMOP.  The  subroutine  ssdrmode()  returns 
TRL'E  if  this  occurs;  FALSE  otherwise. 

r.  char  ssdrjstatus(void) 

This  subroutine  reads  the  status  code  from  the  Solid  State  Data  Recorder 
(SSDR)  and  returns  it  to  the  calling  function. 

s.  char  volt  ages  Jow(  void) 

This  function  checks  the  channel  of  the  Analog-to-digital  (A/D)  Converter 
which  allow  the  measurement  of  voltage  on  the  lOV  bus.  The  value  read  is  converted 
to  voltage  by  the  function  adtoint().  If  that  voltage  falls  below  the  minimum  voltage 
desirable  on  the  lOV  bus,  then  the  function  returns  the  value  TRUE,  meaning  that  the 
voltages  are  too  low,  and  that  the  experiment  should  halt.  Otherwise  it  returns  the  value 
FALSE. 

t.  char  wejlatmched(  void) 

This  subroutine  first  calls  the  function  baro_s>vitch()  to  see  whether  the  ba¬ 
rometric  pressure  switches  have  detected  an  ascent  of  the  Space  Shuttle.  If  this  has  oc¬ 
curred,  or  if  the  Vibration-activated  Launch  Detector  has  detected  a  launch,  this 
function  returns  the  value  DLAUNCH.  Otherwise  it  returns  the  value  FALSE. 

7.  File  fputc.c 

a.  int  fputc(int  chr,  void  *  device) 

The  UNIWARE  compiler  provides  the  standard  C  output  subroutine 
printfO  to  provide  output  to  the  standard  output  device.  However,  this  subroutine  re¬ 
quires  the  user  to  provide  a  subroutine  fputcO  to  handle  the  output  of  a  single  character 
to  any  arbitraiy  device.  We  only  support  output  by  fputcQ  to  the  RS-232C  terminal,  so 
this  subroutine  is  specific  to  that  device. 

This  function  calls  the  subroutine  allow_ctrI_internipts()  to  permit  the  user 
to  interrupt  operation  of  the  control  program.  The  subroutine  will  not  output  a  char¬ 
acter  if,  upon  checking,  it  finds  there  is  no  terminal  attached  to  the  serial  interface  port. 
Thus,  when  the  experiment  is  operating,  calls  to  printfQ  are  of  no  effect  unless  there  is 
a  terminal  connected. 

The  subroutine  returns  —1  if  there  is  no  terminal  connected.  This  is  the 
code  specified  by  UNTWARE  if  fputc()  is  unable  to  do  the  output  operation.  If  there 
is  a  terminal  attached,  fputc()  repeatedly  polls  the  serial  interface,  waiting  for  it  to  be 
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ready  to  accept  output  data.  It  then  outputs  the  character,  and  returns  that  character, 
again  as  specified  by  UNIWARE.  [Ref.  17;  Compiler  Section,  pp.  45  and  52J 

8.  File  global.c 

This  file  contains  the  declarations  of  variables  used  throughout  the  control 
program.  The  author’s  predilection  is  to  avoid  the  use  of  global  variables.  However,  it 
can  sometimes  become  so  awkward  to  observe  this  preference  as  to  make  it  silly.  It  is 
desirable  to  hold  the  use  of  global  variables  to  a  minimum,  however. 

9.  File  inout.c 

a.  void  allow _ctrljnterrupts( void) 

This  subroutine  makes  it  possible  for  the  user  to  interrupt  the  execution  of 
the  control  program.  Whenever  it  gets  control,  it  calls  the  function  Iook_ahead()  to  see 
if  any  key  of  the  terminal  has  been  depressed  by  the  user.  If  not,  then  the  function  re¬ 
turns  without  further  ado.  If  a  key  has  been  depressed,  however,  it  may  have  been  one 
of  the  two  control  keys  CTRL  Y  or  CTRL  S.  If  so.  the  function  termini)  is  called  to 
remove  the  character  from  the  input  buffer,  and  to  respond  appropriately  to  the  input 
control  character. 

b.  void  dump ( unsigned  int  address,  unsigned  int  length) 

This  subroutine  displays  the  contents  of  a  section  of  memor>’  on  the  display 
terminal.  The  variable  address  designates  the  address  of  the  first  character  of  data  to 
be  displayed.  The  variable  length  specifies  how  many  characters  to  display.  The  display 
shows  a  hexadecimal  representation  of  every  character  in  the  chosen  section  of  memory, 
and  if  that  character  has  a  printable  form,  that  form  also  is  displayed.  This  function  is 
of  value  only  for  debugging  the  control  program. 

c.  char  gethe.v(  void) 

This  subroutine  obtains  a  hexadecimal  string  from  the  terminal.  Lp  to 
HSTRLEN  characters  will  be  accepted.  Processing  will  cease  as  soon  as  a  character  not 
in  the  ranges  ‘0’  through  ‘9’,  ‘a’  through  T,  or  ‘A’  through  ‘F’  is  entered.  The  input 
string  will  be  converted  to  a  single  character  by  calling  atohO.  and  this  character  will  be 
returned.  For  example,  the  string  “6a”  would  be  converted  to  the  ASCII  character  ‘j’, 
whose  hexadecimal  representation  is  0x6a.  This  subroutine  is  useful  for  getting  one-byte 
system  port  addresses  from  the  user  if  he  is  more  likely  to  know  them  in  hexadecimal 
than  in  decimal. 

d.  unsigned  int  gethexintf  void) 

This  subroutine  is  very  similar  to  gethexQ,  except  that  it  accepts  two  hexa¬ 
decimal  bytes,  not  just  one. 
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e.  int  getint(  void) 

This  subroutine  obtains  a  decimal  string  from  the  keyboard.  Up  to 
STRLEN  —  1  digits  can  be  entered.  Processing  will  cease  as  soon  as  a  character  not  in 
the  range  ‘0’  through  ‘9’  is  entered.  The  input  string  will  be  converted  to  an  integer  by 
calling  atoi(),  and  this  value  will  be  returned. 

/.  int  getpageno( void) 

This  subroutine  obtains  a  page  number  in  bubble  memory  from  the  user. 
Valid  responses  are  in  the  range  0  through  MAXPAGE.  It  uses  the  subroutine  getintQ 
to  obtain  the  response. 

g.  char  look  jahead(  char  *  character) 

This  function  checks  to  see  if  a  key  has  been  pressed  on  the  display  terminal. 
Of  course,  if  there  is  no  terminal  attached,  there  is  no  point  in  even  looking,  so  the 
function  returns  instantly  in  this  case  with  a  value  of  FALSE.  The  variable 
console_data_available  is  one  of  two  variables  known  to  all  functions  in  the  file  inout.c. 
It  will  have  the  value  TRUE  if  the  function  took_ahead()  or  the  function  termin()  dis¬ 
covered  previously  that  there  was  a  character  available  to  be  read.  The  look_ahead() 
returns  this  character  to  the  calling  function  for  it  to  inspect,  but  it  does  not  remove  the 
character  from  the  bufifer.  Further  calls  to  look_aheadO  or  to  terminQ  would  obtain  the 
same  character. 

If  there  is  no  character  already  in  the  buffer  (that  is.  if 
console_data_available  is  FALSE,)  then  look_ahead()  checks  the  RS232C  interface  to  see 
if  a  key  has  been  pressed.  If  so,  the  character  is  read  and  placed  in  the  variable 
console_buffer  for  future  use  by  look_ahead()  and  termin().  It  also  is  returned  to  the 
calling  function,  and  the  value  of  consoIe_data_avaiIable  is  set  to  TRUE  since  a  character 
now  is  in  the  console  buffer. 

h.  char  ter min(  void) 

The  primary  purpose  of  this  subroutine  is  to  read  a  character  from  the  ter¬ 
minal  whenever  the  latter  has  one  available.  This  condition  is  known  to  be  true  when¬ 
ever  bit  PRTRDY  of  port  PRTCTRL  is  a  1.  The  input  character  is  returned  to  the 
calling  function. 

In  order  to  permit  the  control  program  to  be  interrupted,  however,  the 
function  terminQ  interprets  the  characters  CTRL  S  and  CTRL  Y  specially.  CTRL  S  is 
interpreted  to  mean  “stop  displaying  data  on  the  display  terminal"  if  data  is  being  dis¬ 
played,  or  “start  displaying  data  on  the  display  terminal”  if  the  display  has  already  been 
halted  by  CTRL  S.  In  other  words,  the  CTRL  S  switch  operates  as  a  toggle  switch  to 
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stop  and  start  the  display  of  data.  CTRL  Y  is  interpreted  to  mean  “call  the  diagnostic 
subsystem  menu”.  We  do  not  wish  this  to  be  done  more  than  once  at  a  time,  for  oth¬ 
erwise  we  might  make  so  many  recursive  calls  to  the  program  menu()  that  the  stack 
would  be  corrupted. 

The  variable  allow_menu_call  will  be  TRUE  the  first  time  termin()  is  called. 
If  CTRL  Y  is  entered,  allow_menu_calI  is  set  to  FALSE,  and  further  calls  to  menuQ  are 
precluded  thereafter.  It  is  only  returned  to  the  value  TRUE  if  the  menu()  program  is 
completed  by  the  user  later. 

The  variable  waiting_for_ctls  will  switch  from  FALSE  to  TRUE  or  back 
again  each  time  CTRL  S  is  entered  by  the  user.  Data  from  the  keyboard  will  only  be 
accepted  when  this  variable  is  FALSE,  in  which  case  the  display  has  not  been  halted. 

The  variable  ctrl_valid_data  will  be  a  copy  of  the  variable 
console_data_available  described  earlier. 

If  no  data  has  been  read  into  the  console  buffer  previously  by  terminf)  or 
by  look_ahead().  then  terminO  will  wait  until  a  character  is  available.  Once  this  occurs, 
the  variable  console_data_available  is  set  to  FALSE,  since  terminf)  has  filled  and  emptied 
the  console  buffer  all  at  once.  .A  switch  statement  allows  the  character  to  he  interpreted. 
/.  void  testinput( void) 

This  subroutine  asks  the  user  to  specify  a  port  address  in  hexadecimal.  It 
then  reads  a  character  from  that  pon  and  displays  it  on  the  terminal. 
j,  void  testoutput( void) 

This  subroutine  asks  the  user  to  specify  a  port  address  in  hexadecimal,  and 
then  asks  for  a  hexadecimal  byte  to  be  sent  to  that  port.  The  data  is  accordingly  output 
to  the  port. 

10.  File  main.c 

a.  void  memory  jdump(  void) 

This  subroutine  asks  the  user  for  the  first  address  in  memory  whose  con¬ 
tents  he  wishes  to  inspect,  and  for  the  number  of  characters  which  he  wishes  to  see  dis¬ 
played.  It  then  calls  the  subroutine  dumpQ  to  honor  the  request.  This  function  is  only 
useful  for  very  low-level  debugging  of  the  software. 

b.  void  testio( void) 

This  subroutine  presents  a  menu  permitting  the  user  to  send  data  to  any 
port,  and  to  read  data  from  any  port,  in  the  system.  The  method  of  implementing  a 
menu  is  the  same  as  that  presented  in  the  description  of  the  function  menuf)  and  will  not 
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be  repeated  here.  For  output  to  a  port,  the  function  testinputQ  is  called.  For  input  from 
a  port,  the  function  testoutputQ  is  called. 

11.  File  mbrk.s 

a.  char  *mbrk(long  size,  long  *realsize) 

This  subroutine  is  written  in  Z-80  Assembly  language.  It  is  described  in 
[Ref.  17:  Compiler  section,  p.  51],  from  which  it  is  drawn. 

12.  File  newio.s 

a.  char  input  (char  port) 

This  subroutine  is  WTitten  in  Z-80  Assembly  language.  It  inputs  a  character 
from  a  port  and  returns  it  to  the  calling  function. 

b.  void  output  (char  port,  char  data) 

This  subroutine  is  written  in  Z-80  Assembly  language.  It  outputs  a  char¬ 
acter  to  a  port. 

13.  File  power.c 

a.  void  power _statu$(  void) 

This  subroutine  returns  the  status  byte  from  the  POWERIN’  port.  This 
status  is  described  in  Table  3  on  page  16. 

b.  char  power_write( char  command) 

This  subroutine  issues  commands  to  the  power  circuit  board.  Valid  com¬ 
mands  are  SSDROFF  and  SSDRON  (to  turn  the  Solid  State  Data  Recorder  off  and  on); 
VCOOFF  and  VCOOX  (to  turn  the  Voltage  Controlled  Oscillator  off  and  on);  ADOFF 
and  ADON  (to  turn  the  .Analog  to  Digital  Converter  board  off  and  on);  M.ATFOFF  and 
M.ATFON  (to  turn  power  to  the  matched  filter,  launch  detector  and  barometric  switch 
off  and  on);  and  HEATOFF  and  HEATON  (to  turn  power  to  the  heater  circuit  off  and 
on). 

A  command  can  be  executed  by  writing  it  to  the  POWEROL’T  port  and 
then  setting  bit  PWRSTROBE  in  port  C,  to  a  I.  A  delay  of  length  PWRDELAY  is  re¬ 
quired  before  bringing  that  bit  to  0  again.  Another  delay  of  the  same  length  is  then  re¬ 
quired.  These  delays  ensure  proper  functioning  of  the  relays.  Each  bit  in  the  status  byie 
returned  by  the  function  power_statusO  indicates  whether  the  associated  relay  is  on  or 
off.  The  bit  is  0  if  the  relay  is  on;  1  otherwise.  The  power_>vrite()  function  examines  the 
bit  corresponding  to  the  relay  it  attempted  to  switch.  A  TRUE  is  returned  if  the  relay 
is  in  the  desired  position;  FALSE  is  returned  otherwise. 
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14.  File  start.s 

This  file  contains  the  controller's  start-up  code.  It  is  written  in  Z-80  .Assembly 
language.  Whenever  the  Z-80  receives  power,  it  starts  executing  from  location  0x0000. 
The  start-up  code  initiates  the  stack  pointer  to  the  value  STACKTOP  and  then  causes 
a  jump  to  START.  All  other  Z-80  interrupt  locations  are  initialized  such  that  they  cause 
a  jump  to  the  same  location,  since  interrupts  are  not  used  by  the  controller.  At  START, 
the  L\  register  is  initialized  to  0.  This  register  is  used  by  the  C  compiler  to  point  to  pa¬ 
rameters  and  local  variables  within  C  programs. 

.Memory  may  be  requested  by  C  programs  using  the  mbrk()  function  provided 
with  the  UNIWARE  C  Compiler.  The  start-up  code  uses  a  variable  MBRKPTR  to 
point  to  the  next  available  address  of  allocable  memory.  Initially  this  variable  is  set  to 
MR.AM,  a  global  variable  set  in  the  file  \vibro\control\object\spec  to  point  to  the  begin¬ 
ning  of  all  allocable  memory.  Once  nibrk()  has  obtained  some  memory,  it  keeps  it.  so 
the  start-up  code  never  needs  to  reclaim  it.  Consequently,  MBRKPTR  can  only  in¬ 
crease;  it  can  never  decrease. 

ZR.-\MSZ  is  the  number  of  R.AM  locations  starting  at  ZIUAM  which  are  used 
for  uninitialized,  static  variables  in  the  C  programming  language  subroutines.  The 
start-up  code  writes  zeros  to  all  these  locations,  because  the  C  prograntming  language 
specification  is  that  uninitialized  static  and  external  variables  be  initialized  to  0  by  the 
compiler  (Ref  16:  p.  198]. 

IR,AMSZ  is  the  number  of  R.A.M  locations  starting  at  1R.AM  which  will  contain 
initialized  data.  This  data  is  stored  in  ROM  locations  starting  at  RAMDAT.A  at  the 
time  the  program  is  burned  into  ROM.  The  start-up  code  copies  it  from  RO.M  to  R-A.M. 
Finally,  control  is  passed  to  mam<),  the  user's  C  program.  If  main()  should  ever  return 
control  to  the  start-up  code,  a  halt  instruction  is  executed.  The  start-up  code  is  adapted 
from  an  example  given  in  (Ref  17:  Compiler  Section,  pp.  13-15.] 
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Table  12.  CONTENTS  OF  SUBDIRECTORY  \VIBRO\CONTRLR\BATCH 


File 

Contents 

AS.M.BAT 

This  batch  file  simplifies  the  assembly  of  Z-80  assembly  lan¬ 
guage  source  code.  To  use  it,  type  asm  <  source  filename  >  .s. 
For  example,  to  assemble  the  file  delay.s,  type  asm  delay.s. 

Note  that  the  file  type  need  not  be  s,  but  whatever  it  is,  it  must 
be  present.  Use  of  s  is  recommended  for  clarity.  The  proce¬ 
dure  produces  object  files  in  subdirectory  \vibro\contrlr\object 
and  assembly  code  list  files  in  subdirectory  \vibro\contrlr\list. 

See  the  description  of  the  batch  file  asmlist.bat  for  instructions 
on  how  to  produce  this  listing  file,  which  includes  all  addresses 
supplied  by  the  linker. 

ASMLIST.BAT 

This  batch  file  produces  a  listing  of  the  assembly  language 
source  file  generated  by  the  Z-SO  assembler.  To  use  it,  type 
asinlist  <  filename.filetype  >  .  The  output  is  appended  to  the 
file  \temp\print.  It  can  be  printed  by  use  of  the  batch  file 
promout.bat.  These  listings  include  all  global  addresses  sup¬ 
plied  by  the  linker,  provided  \vibro\contrlr\vibro.out  has  been 
generated  by  promlink.bat. 

C.BAT 

This  batch  file  simplifies  the  compilation  of  C  source  code.  To 
use  it.  type  c  <  source  file  name  >  .c.  For  example,  to  compile 
the  file  vibro.c.  type  c  vibro.c.  Note  that  the  file  type  need  not 
be  c,  but  whatever  it  is.  it  must  be  present.  Use  of  c  is  recom¬ 
mended  for  clarity.  The  procedure  produces  object  files  in 
subdirectory  \vibro\contrlr\object  and  assembly  code  list  files  in 
subdirectory  \vibro\contrlr\list. 

See  the  description  of  the  batch  file  asmlist.bat  for  instructions 
on  how  to  print  listing  files,  which  show  all  addresses  supplied 
by  the  linker. 

LIST.BAT 

This  batch  file  produces  a  listing  of  any  MS  DOS  file.  To  use 
it.  type  list  <  filename.filetype  >  .  The  output  is  appended  to 
the  file  \temp\print.  It  can  be  printed  by  use  of  the  batch  file 

promout.bat. 
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LOADMAP.BAT 


PRINTALL.BAT 


PROMLINK.BAT 


PROMOLT.BAT 


This  batch  file  appends  a  copy  of  the  load  map  into 
\temp\print.  It  can  be  printed  by  use  of  the  batch  file  prom- 
out.bat. 

The  load  map  shows  the  absolute  addresses  at  which  the  eight 
regions  of  code  produced  by  the  compilation,  assembly,  and 
linking  steps  are  placed.  It  is  useful  to  have  this  so  that  you 
know  whether  the  controller  has  enough  R.AM  and  ROVI  in¬ 
stalled  to  hold  the  output  program.  The  listing  shows  the 
starting  address  of  each  region  and  the  number  of  bytes  it  oc¬ 
cupies.  Regions  reset,  code,  const,  string,  and  data  all  must  be 
stored  in  ROM  initially.  Of  these,  only  data  belongs  in  R.AM 
eventually,  yet  it  must  be  stored  in  ROM  initially. 

The  reason  is  that  it  contains  C  variables  whose  values  have 
been  initialized.  If  they  were  not  stored  in  ROM.  those  values 
would  not  be  available  at  execution  time.  The  start  up  routines 
in  \vibro\contrlr\a.smsource\start.s  cause  these  initialized  vari¬ 
ables  to  be  copied  from  ROM  to  their  proper  locations  in 
R.-\M.  These  locations  are  those  shown  in  the  load  map. 

Thus,  in  addition  to  the  ROM  space  required  for  the  other  four 
regions,  be  sure  to  allow  enough  room  for  the  data  region  to 
be  loaded  into  ROM.  too.  For  example,  if  there  is  only  one 
SK  ROM  installed  at  location  O.xOOOO.  but  the  load  map  shows 
that  more  than  SK  of  ROM  is  required,  then  there  is  insuffi¬ 
cient  RO.VI  in  place.  Either  more  must  be  added,  or  the  pro¬ 
gram  must  be  reduced  in  size.  How  to  load  the  executable 
program  into  ROM  is  described  below  in  2.  Getting  the  Exe- 
cutable  Program  into  EPROM  on  page  146. _ 

This  batch  file  will  produce  a  listing  of  all  source  files,  all  batch 
files,  a  load  map,  and  a  symbol  listing.  The  output  will  be  ap¬ 
pended  to  the  file  \temp\print.  Normally  you  would  first  empty 
this  file  using  readyout.bat.  After  producing  a  complete  listing, 
it  could  be  printed  on  the  printer  using  promout.bat. 

This  batch  file  simplifies  the  conversion  of  the  object  modules 
into  an  executable  output  program.  To  use  it.  just  tvpe  prom- 
link. 

It  creates  two  output  files.  The  first  of  these  is 
\vibro\contrlr\vibro.out.  It  contains  information  about  the  ad¬ 
dresses  assigned  by  the  linker  to  global  variables.  This  file  is 
used  by  the  batch  file  promsym.bat. 

The  other  file  which  promlink.bat  produces  is  vibro.hex  which 
can  be  loaded  into  an  EPROM. _ 

This  batch  file  causes  the  file  \temp\print  to  be  printed.  The 
latter  file  contains  the  output  of  the  list,  asmiist.  loadmap,  or 
promsym  batch  file  executions.  It  does  not  erase  \temp\print. 
Use  readyout.bat  to  do  this. _ 
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PROMSYM.BAT 

This  batch  file  appends  a  listing  of  all  the  \  ariables  known 
globally  throughout  the  control  program  to  the  file 
\temp\print.  These  include  both  C  language  source  code  vari¬ 
ables,  Z-80  assembly  language  global  symbols,  and  several 
symbols  defined  by  the  linker  specification  file.  This  listing  is 
useful  in  determining  how  variables  have  been  declared  and  in 
finding  the  absolute  addresses  of  symbols.  It  can  be  printed 
by  use  of  the  batch  file  promout.bat. 

READY- 
OUT.  BAT 

This  batch  file  should  be  used  before  using  anv  of  the  follow¬ 
ing: 

1.  list.bat 

2.  asmlist.bat 

3.  printall.bat 

4.  promsym.bat 

5.  loadmap.bat 

Its  purpose  is  to  empty  the  temporar\'  files  \temp\temp  and 
\temp\print  prior  to  their  being  used  by  those  other  batch  files. 
Once  used,  you  need  not  use  it  again  unless  you  have  already 
printed  the  contents  of  the  temporary  file  and  need  it  no  lon¬ 
ger.  or  unless  you  wish  to  discard  it  for  some  otlier  reason. 

C.  PROGRAM  MAINTENANCE 

This  section  describes  how  to  compile  a  new  version  of  the  controller  program;  and 
how  to  get  an  executable  version  of  that  program  into  an  EPROM.  A  basic  familiarity 
with  Microsoft  MS  DOS  is  assumed.  The  file  organization  is  described  in  APPENDIX 

D.  HIER^ARCHICAL  ORGANIZATION  OF  SOFTWARE  FILES  on  page  88. 

1.  Procedures  for  Generating  a  New  Executable  Program 

a.  Compile  the  C  source  files 

For  each  source  code  file  w’ritten  in  the  C  language,  type  c  <  filename  >  .c. 

b.  Assemble  the  Assembly  Code  Source  Files 

For  each  source  code  file  WTiiten  in  Z-80  assembly  language,  type 
asm  <  filename  >  .s. 

c.  Link  Modules  Together 

Enter  the  command  promlink.  This  links  all  executable  modules  together, 
generating  an  executable  program  module  in  file  vibro.bin  in  subdirecton.’  \vibro\contrIr, 
which  becomes  the  current  directory  upon  completion. 
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Table  13.  CONTENTS  OF  SUBDIRECTORY  \VIBRO\CONTRLR\CSOURCE 


File 

Contents 

BLBBLE.C 

Contains  programs  which  operate  the  bubble  memory  module 
on  the  controller  board. 

CLOCK.C 

Contains  programs  which  operate  the  real  time  clock  on  the 
controller  board. 

CONVERT.C 

Contains  programs  which  perform  conversion  of  data  from  one 
format  to  another. 

EXP.MNT.C 

Contains  programs  which  are  specially  designed  for  use  with 
the  Vibro-accustic  Experiment.  They  are  not  usable  by  other 
applications,  although  they  might  be  tailored  to  them. 

FPLTC.C 

Contains  the  routine  fputc(). 

GLOBAL.C 

Contains  the  declarations  of  the  few  variables  which  are  de¬ 
clared  with  global  scope  (/.e.,  which  are  known  to  all  subrou¬ 
tines). 

IMTIAL.C 

Contains  programs  which  initialize  both  NSCS10.-\ 

R.AM -10- Timer  chips  on  the  controller  board. 

INOUT.C 

Contains  programs  which  handle  input  from  and  output  to  any 
device. 

MAIN.C 

Contains  the  highest  level  of  programs  which  operate  the  con¬ 
troller,  including  the  C  subroutine  malnO.  These  include  most 
of  the  menu-driven  routines  which  are  e.xecuted  if  there  is  a 
terminal  attached  to  the  controller  when  it  receives  power. 

POWER.C 

Contains  programs  which  operate  the  electrical  power  relay 
board  in  the  controller.  This  board  supplies  power  to  various 
hardware  subsystems. 

2.  Getting  the  Executable  Program  into  EPROM 

a.  Copy  the  Executable  Program  to  a  Diskette 

Place  a  5  l!4  inch  diskette  in  drive  B.  Then  enter  the  command  copy 
vibro.hex  b:.  This  puts  a  copy  of  the  file  vibro.liex  on  the  diskette.  This  file  contains  a 
hexadecimal  format  of  the  code  which,  when  loaded  into  an  EPROM,  will  allow  the 
controller  to  function. 

b.  Prepare  to  Write  EPROMs 

We  have  acquired  the  Intel  program  PCPP  PC  Personal  Programmer  to 
load  data  into  EPRO.Ms.  Take  the  diskette  to  the  IBM  Personal  Computer  (PC)  with 
the  EPROM  programmer.  This  PC  is  located  in  Space  Lab  #2,  Room  102,  Bullard  Hall, 
Naval  Postgraduate  School.  Be  sure  you  have  enough  EPRO.MS  available. 
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Table  14.  CONTENTS  OF  SUBDIRECTORY 
_ \VIBRO\CONTRLR\ASMSOURC 


File 

Contents 

BUBRW.S 

This  file  contains  the  routines  bubread(),  bubwrite()  and  bubx- 
fer().  These  routines  had  to  be  written  in  assembly  language 
because  the  compiled  code  would  not  execute  fast  enough  cor¬ 
rectly  to  perform  data  transfers  with  the  bubble  memory  con¬ 
troller.  Each  routine  looks  just  like  a  C  language  subroutine 
to  the  calling  routine. 

DELAY.S 

This  file  contains  a  delay  routine  written  in  Z-80  assembly 
code,  but  it  can  be  called  as  if  it  were  a  C  language  subroutine. 
Its  purpose  is  to  provide  delays  in  multiples  of  10  ms  in  situ¬ 
ations  where  the  hardware  requires  it. 

MBRK.S 

This  is  a  routine  supplied  with  the  L'NTWARE  C  compiler.  Its 
purpose  is  to  allow  C  programs  to  request  memory  through  the 
standard  allocation  routines  malloc()  and  callocQ 
(Ref  17:  Compiler  section,  pp.  iO-ol]. 

NEWIO.S 

This  file  contains  the  two  routines  input!)  and  oufput().  They 
are  written  in  Z-SO  assembly  code,  but  they  can  be  called  as  if 
they  were  C  language  subroutines.  They  provide  the  ability  to 
read  characters  from  and  write  characters  to  any  valid  port 
address. 

START.S 

This  file  contains  the  Z-80  initialization  code,  such  as  an  ad¬ 
dress  where  execution  should  begin,  interrupt  vectors,  code  for 
initializing  RAM,  and  a  call  to  the  main!)  program,  located  in 
the  C  source  file  vibro.c.  It  is  adapted  from  code  provided  bv 
UNTWARE. 

To  ensure  they  are  empty,  place  them  in  the  EPROM  eraser  and  turn  on  the 
fluorescent  light  to  erase  their  contents.  While  this  is  going  on,  and  once  the  PC  is 
booted  up,  enter  the  command  cd  pcpp  at  the  command  line.  This  will  make  pcpp  the 
current  subdirectory,  and  so  the  program  pcpplod  can  be  issued  to  initialize  the  program 
which  will  write  the  file  vibro.hex  into  the  EPROMs.  Once  this  has  been  done,  enter  the 
command  ipps  channel(3),  which  actually  invokes  PCPP. 

PCPP  now  has  control.  Enter  the  follomng  commands: 
t  2764  This  command  allows  2764  EPROMs  to  be  used. 

i  80  This  specifies  that  INTEL  8080  hex  format  files  are  being  used. 

This  is  the  format  of  the  program  in  the  file  vibro.hex. 


Table  15.  CONTENTS  OF  SUBDIRECTORY  \VIBRO\CONTRLR\HEADERS 


File 

Contents 

BUBBLE.H 

This  file  contains  the  extern  declarations  of  the  routines  in 

bubble.c. 

BUBRW.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
bubnv.s. 

CLOCK.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
clock.c. 

CONVERT.  H 

This  file  contains  the  extern  declarations  of  the  routines  in 
convert.c. 

DEL.AY.H 

This  file  contains  the  e.xtern  declarations  of  the  routines  in  de- 
lay.s. 

EXPMNT.H 

This  file  contains  the  e.xtern  declarations  of  the  routines  in 

expmnt.c. 

GLOB.XL.H 

This  file  contains  the  e.xtern  declarations  of  the  variables  in 
global.c. 

INTTl.AL.H 

This  file  contains  the  e.xtern  declarations  of  the  routine  in  ini- 
tial.c. 

INOUT.U 

This  file  contains  the  e.xtern  declarations  of  the  routines  in  in- 
out.c. 

M.AIN.H 

This  file  contains  the  e.xtern  declarations  of  the  routines  in 
main.c. 

NEWlO.H 

This  file  contains  the  e.xtern  declarations  of  the  routines  in 
ne'vio.s. 

POWER.H 

This  file  contains  the  extern  declarations  of  the  routines  in 
pover.c. 

VIBRO.H 

This  file  contains  definitions  of  all  constants  used  by  the  C 
routines.  It  also  contains  definitions  of  global  structures  used 
throughout. 

b  This  performs  a  check  to  ensure  the  EPROM  currently  loaded  in 

the  socket  is  blank.  It  should  be  obvious  that  a  blank  EPROM 
must  be  inserted  in  the  slot  before  performing  this  check. 

c.'vibro.hex  (0000,  Ifff)  t  p 

c:vibro.hex  (2000, 3ff0  t  p 

c’.vibro.hex  (4000,5ffT)  t  p 

c:vibro.hex  (6000, 6c23)  t  p 

crvibro.hex  (e000,el27)  t  p  (0c24) 
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The  last  five  commands  copy  the  program  instructions  from  the  diskette  into  the  EP¬ 
ROM.  The  numbers  in  parentheses  are  the  addresses  which  are  to  be  loaded  into  each 
EPROM.  A  new  EPRO.M  should  be  inserted  into  the  socket  prior  to  executing  each  of 
the  first  four  commands.  The  number  0x6c23  in  the  fourth  command  is  one  less  than 
the  number  RA.MDATA  in  the  symbol  table.  The  number  0el27  is  one  less  than  the 
value  of  ZRAM  in  the  symbol  table.  The  number  0x0c24  is  0x6000  less  than  the  number 
RA.MDATA  in  the  symbol  table.  This  number  tells  the  PCPP  program  where  in  the  fi¬ 
nal  EPROM  to  begin  writing  this  section  of  data.  Since  the  EPROM  addresses  all  are 
in  the  range  [0x0000,0x1  fif],  subtracting  0x6000  from  the  actual  starting  address  is  nec¬ 
essary  to  get  the  address  into  the  proper  range.  Note  that  the  last  command  causes  the 
data  which  eventually  will  be  placed  in  RAM  to  be  loaded  at  the  end  of  all  the  data 
which  is  to  remain  in  EPROM  locations.  It  is  conceivable  that  this  information  would 
not  fit  onto  the  end  of  a  single  EPROM  but  might  spill  across  the  end  and  require  an¬ 
other  EPROM.  This  would  require  modifying  the  instruction  sequence  shown  above. 
For  details,  consult  [Ref  20].  The  command  exit  will  terminate  the  operation  of  the 
PCPP  program. 

This  completes  the  loading  of  the  control  program  into  EPROM.  The  EP¬ 
ROMs  can  now  be  loaded  into  the  controller  for  testing. 
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APPENDIX  H.  CONTROL  PROGRAM  SOURCE  CODE 


A.  FILENAME  SPEC 


Specification  fila  for  tha  Controllar  Kar^«ara.  Also  saa 
eonpanion  files  “start. ase"  and  “mbrK.asn".  This  specification 
assuses  32K  of  ROM  at  address  0x0000,  and  8K  of  RAM  at  address  OxaOOO. 

. . . 

partition  { 
overlay  < 

region  {}  reset  (addr  >  Oil  /a  reset  vector  »/ 
region  <}  code,  const,  strings  /a  other  ROM  a/ 

RAMOATA  =  /a  ROM  to  initialize  region  ram  a/ 

Region  ram  is  initialized  at  rtzitime  startup  by 
copying  data  from  RAMOATA  to  IRAM.  Tha  data  must 
actually  be  linked  to  its  RAM  address  (IRAM)  to  get 
correct  variable  addresses,  but  must  be 
programmed  into  ROM  here.  By  hand,  you  must 
ensure  that  ENOOATA  <=  ENORQM.  (ENDOATA  is  below) 
»<MHHHnnnHHt«<nntae«<n>«aaa)>»)nnta<nmaaa<n>»wa<H>»innHHn>a»<Hnta/ 

ENOROM  s  0x8000)  /a  end  of  ROM  a/ 


IRAM  s  OxeOOO) 

region  <}  data  [ addrsQxeOOO  I ) 

IRAMSZ  s  t  -  IRAM) 


/*  RAM  starts  here,  a/ 

/a  RAM  to  be  initialized  on  reset  a/ 
/a  «  bytes  to  copy  from  RAMOATA  a/ 


ENOOATA  *  RAMOATA  ♦  (♦  -  IRAM))  /a  compere  this  against  ENOROM  a/ 


ZRAM  ::  $) 
region  {}  ram) 

ZRAMSZ  s  «  -  ZRAM) 

MRAM  >  *) 

region  {}  mbrKramisizeaOxZSOli 
MRAMSZ  s  f  .  MRAM) 

region  O  stack  CsizeaOxSOO]) 
STACKTOP  >0x10000) 

}  O) 

}  p  (sizeaOxlOOOOl) 


/a  Pointer  to  start  of  ram  region, 
/a  RAM  to  be  zeroed  on  reset  a/ 

/a  It  bytes  to  zero  on  reset  »/ 


/a  RAM  available  to  nalloc( )  a/ 


/a  stack  of  at  least  0x500  bytasa/ 
/a  stack  pointer  reset  value  a/ 


a/ 


B.  FILENAME  VERSION.H 

axtam  void  version! void)) 
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C.  FILENAME  VERSION.C 

void  vorsionlvoid)> 

. . . 

void  vorsionC void) 

< 

printfC 

“\n,rControl  proflron  for  tho  SpMO  Shufflo  Vibro-oeoustic  Exporinont.  n  r\ 
Vor«ion  «.19  April  14,  1989n,r")) 

} 


D.  FILENAME  VIBRO.H 

/»  vibro.h  */ 


bdafine 

TRUE 

Oxff 

bdef ine 

FALSE 

0x00 

bdafine 

EXPERIMENTOK  0X11  /a 

bdafine 

SELECT 

0x1 

/a 

bdafine 

ASCII 

0 

/a 

bdafine 

HEX 

1 

/a 

bdafine 

NULL 

0x00  /a 

The 

bdafine 

BELL 

0x07 

bdafine  BS 

0x08 

bdafine  CTRLS 

0x15 

/a 

bdafine 

CTRLY 

0x19 

/a 

bdafine 

SPACE 

0x20 

bdafine 

DELETE 

0x7f 

bdafine 

STANDBY 

0x01 

/a 

bdafine 

SHEEP 

0x02 

/a 

bdafine 

SCROLL 

0x04 

bdafine 

LAUNCH 

0x08 

bdafine 

RECORD 

0x10 

bdafine 

PLAYBACK  0x20 

bdafine  OPCOMP 

0x40 

bdafine  NORMOP 

0x80 

As  a  paramaior  fo  monut  ),  fhis  true  flag 
permits  the  experiment  to  be  run.  */ 

Select  appropriate  power  relay.  */ 

Used  as  a  parameter  to  showbubbufft  ).  »/ 
Used  as  a  parameter  to  showbubbuff(  ).  •/ 
following  are  ASCII  definitions.  «/ 


Permits  output  to  be  halted  and  restarted. 

Permits  the  menu! )  program  to  be  entered 
recursively  anytime  console  I/O  takes  place. 

Only  one  recursive  call  at  a  time  is  supported.  */ 


These  ere  mesks  for  the  SSDR  commands  and.  •/ 
status  codes.  */ 


bdefine  TRIES  5  /«  Huthmr  of  times  to  try  something  before  giving  */ 


bdefinm  BLOCKS_PER_PAGE  2 

/*  The  number  of  date  blocks  per  page 
of  bubble  memory,  a/ 

bdefina  RECORD_OELAY  12  /*  The  rxanber  of  hours  to  wait  after  initiating 

RECORD  mods  before  daring  to  restart  it.  «/ 


/«  The  following  constants  are  used  by  the  routine  adtointi  )  to  convert 

values  read  by  the  A/0  converter  into  the  corresponding  real-world  «xiits.  a/ 
bdafine  MULT_TEMP  1940784L  /a  uK  per  i«it  on  the  A/0  converter,  a/ 
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(tdafin*  HULT.IOV  4M2745L  /»  10E-2V  par  unit  on  tho  A/D  oonvortor.  »/ 

«dofirM  MULT_20V  9725490L  /»  10E-2V  p«r  unit  on  tha  A/0  oonvortor.  «/ 

Mofino  M1N_VOLTA6E_10  850  /»  8.50  V  i*  tho  oinimtai  poroissiblo 

voltogo  on  tho  lOV  bu«.  Tho  oonstont 
roprooonts  this  in  units  of  lE-2  V.  o/ 

Ddofino  MX(i.0PERATXN6_TENP  283  /»  Tho  bUbblo  ooM>rios  should  not  bo  oporotod 

if  tho  tsiyisroturo  foils  boloM  10  dograos  C 
or  283  K.  »/ 

Mafino  MXH_DESIRABLE_TEHP  285  /»  Tho  haotors  should  bo  on  if  tha  taayioraturo 

is  baloM  285  K.  */ 

«dofino  MAX_DES1RABLE_TEHP  287  /«  Tha  haotors  should  bo  off  if  tho  to^>oraturo 

is  abovo  287  K.  a/ 

8dofino  BUBDATA  0x40  /a  I/O  port  for  tho  controllar's  bi^lo  oaoory .  a/ 
Mofino  BUBCTRL  0x41  /a  Control  and  status  port  for  tho  BMC.  a/ 

/a  Tho  following  codas  ara  coaoiands  to  tho  bUbblo  oomory  controllor.  a/ 

«dafino  BABORT  0x19 

ffdefina  BINIT  0x11 

Rdofino  BFIFORESET  0x10 

Rdafino  BHRBLRE6  0x16  /a  Nrita  boot  loop  ragistor.  a/ 

Bdofino  BREAD  0x12 

Bdofino  BWRITE  0x13 

Bdofino  BLDPARM  OxOb  /a  Load  paramatric  rogistars.  a/ 

ffdafina  BTRIES  30000  /a  Bubbla  commands  should  ba  writtan  this  a/ 

/•  many  timas  bafora  giving  up  in  disgust,  a/ 

/a  Tho  following  aro  bubbla  saasory  oontrollor  status  codas,  a/ 

Vdofino  BBUSY  0x80 

ffdafino  BOPCOMPLETE  0x40 
ffdafino  BFAIL  0x20 

Pdefina  BTIMIN6  0x02 

ffdafino  BFIFO  0x01 

Rdafino  BBUSYBIT  7  /*  Thoso  constants  spocify  which  bit  in  tho  •/ 

Bdofino  BOPCOMPLETEBIT  6  /a  BMC  status  bit  is  usad  for  which  purposo.  «/ 

«dafino  BFAILBIT  5 

8dafino  BFIFOBIT  0 

ffdafino  BNEVER_REA0Y  0 
tdofino  BXFER_GOOO  1 

Bdofino  BXFER_B«0  2 

Mmiinm  PA6ELEN6TH  64  /a  Tho  manbor  of  bytos  in  a  pago  of  biisblo  mamory.  a/ 

«dofino  MAXPA6E  8191  /a  Qrootost  valid  btiibla  oomory  poga  nudaor.  a/ 


Bdafino  ADPOINTS  10  /a  Tho  madior  of  analog  quantitios  to  bo  oonvortod  to 

daoioal.  a/ 

Bdafino  STRLEN  7  /a  Nudtar  of  cha  roc  tors  to  allow  for  intagor 

oharootors*  including  a  null  toroinater.  a/ 
Bdafino  HSTRLEN  2  /a  Nuabor  of  oharoetors  to  allow  for  hoxadoeioal 

charactorsa/ 

Bdafino  HEXXNTSTRLEN  4  /a  Nuabor  of  oharoetors  in  a  hoxadoeioal  word,  a/ 
Bdafino  DUMPNIDTH  16  /a  Nudbor  of  bytos  in  a  lino  of  a  oaoory  dLos>.  a/ 
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/»  Bit  dafinitions  for  port  C  of  NSC810  Bl.  (Bom  oddroso  io  0x00.  I 
Bit  «  MEANING 
5  Sparo  output. 

4  PoMor  strobo  output  (Active  hi^). 

3  Ono  if  no  torminal  ia  connoctad  to  tha  RS-Z32C  port. 

Zero  if  a  terminal  ia  connected. 

2  Barometric  preaaura  drop  detection  after  launch 

(active  high). 

1  Vibration  detection  at  lacnch(active  high). 

0  Matched  filter  detection  of  Auxiliary  PoMor  Uhit  (APU) 

prior  to  launch  (active  high). 

»/ 


Bdef ine 

TERMON 

0x08 

Bdef ino 

BARO_0N 

0x04 

Bdef ine 

VIB_0N 

0x02 

Bdef ine 

APU_0N 

0x01 

/*  Pointa  to  the  terminal  connection  line  in  NSC810  Bit 
Port  Ct  Pin  3.  It  ia  zero  nhan  tha  terminal  ia 
cormeetad.*/ 

/*  Barometric  preaaura  drop  line.  */ 

/*  Vibration  detection  line.  */ 

/*  APU  detection  line.  »/ 


/•  Bit  definitions  for  port  C  of  NSC810  B2.  (Base  addresa  ia  0x20.  ) 

Bit  B  Meaning 

5  RESET*  line  for  the  bubble  memory.  This  line  should  be 

zero  whenever  power  is  applied  to  or  removed  from  the 
bubble  memory.  It  is  one  normally.  The  purpose  of 
making  it  zero  during  power  switching  is  to  avoid  havin 
to  meet  the  strict  requirements  for  power  rise  and  fall 
tims  which  would  be  necessary  otherwise. 

4  Power  line  for  the  bubble  memory.  This  line  is  a  one 

to  apply  power)  a  zero  to  remove  it. 

3  End  of  analog  to  digital  conversion.  (Active  high?) 

2  Spare  input. 

1  Spare  input. 

0  Heater  control  output  (active  high). 


*/ 

Bdef ine 

READCl 

0x02 

/» 

Points 

to 

tho 

Nsceio 

Bl, 

Port 

C,  R/)f  register.  */ 

Bdef ine 

BCLRCl 

OxOa 

/» 

Points 

to 

tho 

NSC810 

Bl, 

Port 

C,  Clear  register.  */ 

Bdef ine 

BSETCl 

OxOe 

/* 

Points 

to 

th« 

Nscaio 

Bl, 

Port 

C,  Sot  register.  */ 

Bdef ine 

BCLRC2 

0x2a 

/* 

Points 

to 

the 

NSC810 

B2, 

Port 

C,  Clear  register.  */ 

Bdef ine 

BSETC2 

0x2e 

/* 

Points 

to 

the 

NSC810 

B2, 

Port 

C,  Set  register.  »/ 

Bdef ine 

PWRSTR08E  0x10 

/» 

Points 

to 

the 

power  board  relay  strobing  line.  To 

turn  on  a  peripheral*  you  must  strobe  this  line  high 
for  PWROELAY  «  10  ms.  This  line  is  NSCBIO  Bl* 

Port  C,  Pin  4.  */ 


/«  These  are  port  eddresses  for  the  A/D  converter.  Charmeter  strings  »ri%ich 
identifiy  these  ere  defined  in  file  "global. c”.  Be  sure  that  changes 
in  one  piece  are  Mtched  in  the  other.  */ 


Bdef ine  VOLTO 

0x80 

Bdafina 

VOUTl 

0x81 

Bdef ine 

VOLT  2 

0x82 

Bdefine 

TEMPO 

0x83 

Bdafina 

TEMPI 

0x84 

Bdefine 

TEMP2 

0x85 

Bdafina 

TEMP3 

0x86 

Bdafina 

TEMP4 

0x87 

Bdefine 

TEMPS 

0x88 

Bdefine 

TEMP6 

0x89 

/•  Voltage  from  tZO  V  bus.  •/ 

/*  Voltage  from  -20  V  bus.  */ 

/«  Voltege  from  tlO  V  bus.  •/ 

/*  Tenyerature  from  shelf  above  BMC.  •/ 

/«  Temperature  from  inderaide  of  speaker.  */ 
/»  Temperature  from  shelf  above  battery.  •/ 

/*  Temperature  from  batteries.  */ 

/•  Temperature  from  controller's  backplane.  •/ 
/*  Temperature  from  card  8  of  BMC.  •/ 

/*  Temperature  from  card  9  of  BMC.  */ 


153 


bdef ine 

PNRDELAY 

2  /* 

The  number  of  10  ms  units  that  the  power  board 

strobe  should  be  applied  to  turn  on  a  relay.  */ 

Bdefina 

BUBRST 

0x20 

/*  Points  to  the  RESET*  line  in  NSC810  B2,  Port  C> 

Pin  5.  »/ 

Bdefina  BUBPNR 

0x10 

/*  Points  to  the  bubble  power  line  in  NSC810  B2> 

Port  C>  Pin  4.  «/ 

Bdafine 

BUBOELAY 

5  /» 

Number  of  10  ms  ixiits  to  wait  whan  operating  the 
bubble  memory.  */ 

Bdafine  MORI 

0x07 

/*  See  the  documentation  for  a  description  of  the  */ 

Bdefine 

OORAl 

0x04 

/*  use  of  these  ports.  »/ 

Bdefine 

DORBl 

0x05 

Bdefine 

OORCl 

0x06 

Bdefine 

TMOl 

0x18 

Bdefine 

TOLBl 

0x10 

Bdefine 

TOHBl 

0X11 

Bdefine 

STARTOl 

0x15 

Bdefine 

M0R2 

0x27 

Bdefine 

0DRA2 

0x24 

Bdefine 

D0RB2 

0x25 

Bdefine 

00RC2 

0x26 

Bdefine 

TM02 

0x38 

Bdefine 

T0LB2 

0x30 

Bdefine 

T0HB2 

0x31 

Bdefine 

START02 

0x35 

Bdefine 

PRTOATA 

OxcO 

/«*  Port  number  for  data  from  RS-232C  interface.  »/ 

Bdefine 

PRTCTRL 

OxeO 

/»  Port  number  for  control  information  from  RS-232C 
interface.  */ 

Bdefine 

PRTOUTRDY  0x01 

/»  Bit  zero  of  the  PRTCTRL  byte  is  a  one  if  the  printer 
is  ready  to  accept  data  and  zero  otherwise.  */ 

Bdefine 

PRTRDY  1 

0x02 

/»  Bit  one  of  the  PRTCTRL  byte  is  a  one  if  there  is 

data  to  ba  raad  and  zero  otherwise. 

/*  Bit  meanings  for  the  power  status  byte  at  address  POHERIN. 

Bit  Meaning 

5  1  if  heater  circuit  is  offi  0  if  it's  cn. 

4  1  if  matched  filter  lAPU  detection)  circuit  is  off) 

0  if  it's  on. 

3  1  if  analog  to  digital  converter  lA/D)  circuit  is  off) 

0  if  it's  on. 

2  1  if  voltage  controlled  oscillator  IVCO)  is  off) 

0  if  it's  on. 

1  1  if  solid  state  data  recorder  ISSOR)  is  off) 

0  if  It's  on. 

The  saise  bit  assignments  apply  to  the  power  cosewnd  byte  at  address  PONEROUTt 
but  the  bits  have  a  different  meaning.  A  one  in  bits  1-5  is  used  to  select  the 
corresponding  relay.  A  zero  is  used  to  cause  that  relay  to  be  ignored. 

A  one  in  bit  zero  causes  the  selaotad  relays  to  be  switched  an.  A  zero  in 
bit  zero  causes  the  selsoted  relays  to  ba  switohad  off. 

•/ 

Zdefina  PMR_RELAYS  5  /*  The  manber  of  power  relay  switches.  •/ 

Sdefine  POHEROUT  0x01  /*  Port  address  for  power  control  board  commands.  */ 
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POHERIN  0x21  /»  Port  oddros*  for  poMor  control  board  atatua.  a/ 

Mafina  SSOROUT  0x00  /»  Port  addraaa  for  SSOR  coaananda.  */ 

Odafina  SSORIN  0X01  /*  Port  addraaa  for  SSOR  atatua.  a/ 

Rdafina  SSOROFF  0x02  /a  Tha  following  ara  eoiwaartda  for  applying  or  ranovinga/ 
Rdafina  SSDRON  0x03  /a  powar.a/ 

Rdafina  VCOOFF  0x04 

Odafina  VCOON  0x05 

Rdafina  AOOFF  0x08 

8dafina  AOON  0x09 

ttdafina  HATFOFF  0x10 

Rdafina  MATFON  0x11 

Rdafina  HEATOFF  0x20 

8dafina  HEATON  0x21 

Odafina  ONBIT  0x01  /a  Tha  lowanaoat  bit  of  a  powar  coiaaand  ia  1  to  turn 

power  on>  0  to  turn  it  off.  a/ 

Rdafina  NOPONER  OxCl  /a  Maak  for  taipar  2  bita  and  bit  0  in  powar.  Thaaa 

bita  hava  no  moaning  whan  you  axaaina  tha  powar 
board* a  atatua. a/ 

/a  Thaaa  ara  avant  codaa  usad  for  logging  evanta.  a/ 

/a  Oont*  altar  thaaa  codaa  without  adjusting  show_avant(  )  accordingly,  a/ 

/a  A  prafic  C  maans  COMMAND  ISSUED. 

A  prefix  CF  means  COMMAND  FAILED. 

A  prefix  CS  means  COMMAND  SUCCEEDED. 

A  prefix  0  means  SOMETHING  WAS  DETECTED  OR  DONE.  »/ 

Rdefine  INITIALIZE  0  /a  Start  with  aplomb,  a/ 

Pdefine  CSWEEP  1  /a  SSOR  was  commanded  to  enter  SWEEP  moda.  */ 

Pdefina  CSSWEEP  2  /*  SSOR  accepted  a  SWEEP  command,  a/ 

•define  CFSWEEP  3  /a  SSOR  wouldn't  accept  a  SWEEP  command,  a/ 

•define  OSWEEP  4  /a  Tha  sweep  was  completed  successfully,  a/ 

•define  OAPUON  S  /*  Tha  auxiliary  powar  unit  was  detected  ON.  a/ 

•define  CSCROLL  6  /a  SSOR  was  commanded  to  enter  SCROLL  mode,  a/ 

•define  CSSCROLL  7  /a  SSOR  accepted  a  SWEEP  command,  a/ 

•define  CFSCROLL  8  /a  SSOR  wouldn't  accept  a  SCROLL  comawnd.  a/ 

•define  OLAUNCH  9  /a  A  launch  was  detected.  »/ 

•define  CLAUNCH  10  /a  SSOR  was  comaandad  to  antar  LAUNCH  moda.  «/ 

•dafina  CSLAUNCH  11  /a  SSOR  accepted  a  LAUNCH  command,  a/ 

•define  CFLAUNCH  12  /a  SSOR  wouldn't  accept  a  LAUNCH  command,  a/ 

•dafina  DPRESSURE  13  /a  The  pressure  switch  detected  a  prasaura  drop. a/ 

•define  DNOOPCOMP  14  /a  SSOR  didn't  report  completion  in  the 

allotted  time,  a/ 

•dafina  OOPCOMP  15  /a  SSOR  completed  its  SWEEP  or  LAUNCH  moda.  a/ 

•define  DABORT  16  /a  Na  think  tha  mission  was  abortad.  a/ 

•dafina  CONSSDR  17  /a  Tha  SSOR  powar  on  ccaaaand  was  issued,  a/ 

•define  CSONSSOR  18  /a  The  SSOR  powar  on  command  succeeded,  a/ 

•define  CFONSSOR  19  /a  The  SSOR  powar  on  ewmaand  failed,  a/ 

•define  COFFSSOR  20  /a  The  SSOR  powar  off  eoaamind  was  issued,  a/ 

•define  CSOFFSSDR  21  /a  Tha  SSOR  powar  off  eoaamind  auocaaded.  a/ 

•define  CFOFFSSOR  22  /a  Tha  SSOR  power  off  ooaaaand  failed,  a/ 

•define  COFFVCO  23  /a  Tha  VCO  powar  off  eioasaand  was  issued,  a/ 

•define  CSOFFVCO  24  /•  Tha  VCO  powar  off  command  suooaadad.  a/ 

•define  CFOFFVCO  25  /a  Tha  VCO  power  off  eaamiand  failed,  a/ 

•define  CONVCO  26  /a  The  VCO  powar  on  oommand  was  issued.  »/ 

•define  CSONVCO  27  /a  Tha  VCO  powar  on  oommand  suooaadad.  a/ 

•define  CFONVCO  28  /a  Tha  VCO  powar  on  command  failed,  a/ 

•define  COFFAO  29  /a  Tha  AD  powar  off  comsiand  was  issued,  a/ 

•define  CSOFFAO  30  /a  Tha  AO  powar  off  command  suooaadad.  a/ 
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ttdafin*  CFOFFAD  31  /»  Th«  AD  powar  off  command  failed.  */ 

<kj«fina  CONAD  32  /*  The  AD  power  on  command  was  issued.  */ 

Mefine  CSONAD  33  /e  The  AO  power  on  command  succeeded.  */ 

^define  CFONAO  34  /*  The  AO  power  on  command  failed.  */ 

4tdefine  COFFMATF  35  /•  The  HATF  power  off  command  was  issued. 

#define  CSOFFNATF  36  The  MATF  power  off  command  succeeded.  »/ 

Mefine  CFOFFHATF  37  /»  The  HATF  power  off  command  failed.  »/ 

ffdefine  COftlATF  38  /e  The  MATF  power  on  eonmiand  was  issued.  »/ 

Mefine  CSONMATF  39  The  MATF  power  on  command  succeeded,  a/ 
ttdefine  CFONMATF  40  /«  The  MATF  power  on  command  failed,  a/ 
ttdefine  COFFHEAT  41  /a  The  HEAT  power  off  command  was  issued,  a/ 

^define  CSOFFHEAT  42  /a  The  HEAT  power  off  command  succeeded,  a/ 

^define  CFOFFHEAT  43  /a  The  HEAT  power  off  command  failed,  a/ 

^define  CONHEAT  44  /a  The  HEAT  power  on  command  was  issued,  a/ 

Mefine  CSONHEAT  45  /a  The  HEAT  power  on  command  succeeded,  a/ 

Mefine  CFONHEAT  46  /a  The  HEAT  power  on  command  failed,  a/ 

^define  READAO  47  /»  He  read  the  A/D's.  a/ 

Mefine  TERMINATE  48  /a  Finish  gracefully,  a/ 

Mefine  DUSERNOAPU  49  /a  The  user  ferminafed  the  wait  for  the  APUs.  a/ 
^define  INVALIDCOMHANO  50  /a  Th.s  code  is  regarded  as  invalid>  and  should 

never  occur.  It  is  provided  to  help  in 
debugging  the  software,  a/ 

Rdefine  PRIORLAUNCH  51  /a  If  power  is  restored  after  the  launch  has  already 

besp^i  then  this  mission  status  is  assigned,  a/ 

Mefine  CSRECORD  52  /*  The  RECORD  mode  command  succeeded,  a/ 

Mefine  CFRECORO  53  /a  The  RECORD  mode  command  failed,  a/ 

/a  Various  constants  used  for  setting  the  parametric  registers,  a/ 

Rdefine  BBLKLNM  0x10  /a  Block  length  register  MSB.  64  bytes/page.  a/ 

Mefine  BBLKLNL  0x01  /a  Block  length  register  LSB.  1  page/transfer,  a/ 

Mefine  BMBMSEL  0x00  /a  Bubble  memory  select  (MBM).  Only  1  module 

connected,  a/ 

Rdefine  BENREG  0x20  /a  Enable  register.  Polling  node,  a/ 

Rdefine  THOUSANDTHS  0x60  /a  The  ports  for  reading  the  data  and  time,  a/ 

Mefine  HUNDREDTHS  0x61 

Mefine  SECONDS  0x62 

Rdefine  MINUTES  0x63 

Mefine  HOURS  0x64 

Rdefine  HEEKDAY  0x65 

Rdefine  DATE  0x66 

Mefine  MONTH  0x67 

struct  datatima  {  /a  This  structura  contains  binary  coded  a/ 

char  month)  /a  decimal  data  as  dafinad  for  tha  National  a/ 

char  data)  /a  Semiconductor  MM58167A  Microprocessor  a/ 

char  hour)  /a  Real  Tima  Clock,  a/ 

char  minuta) 

char  second) 

char  hundredths) 

char  theusandths ) 

>) 

struct  idatetima  <  /a  This  structure  contains  tha  same  a/ 

int  imonth)  /«  information  as  tha  datatima  structural  but*/ 

int  idate)  /a  in  integer  format,  clockinti )  takas  care  «/ 
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/*  of  convorting  fro*  BCD  to  intogor  format.  «/ 


int  ihour) 
int  iminutat 
int  isacond) 
int  ihundredths i 
int  i thousandths i 


/a  This 

structure  dascribas  tha  uses 

of  tha  bits 

in  the  power  relay  control 

port. 

,  a/ 

struct  power_port_fmt  { 

char 

:2> 

/a 

Upper 

two  bits  are 

not 

used.  »/ 

char 

heatar:!) 

/a 

Bit 

5 

- 

designs tas 

tho 

heater  circuit. 

char 

matchad_f iltar :  1 1 

/a 

Bit 

4 

- 

designates 

tho 

matched  filter. 

char 

a_to_d:l» 

/a 

Bit 

3 

- 

designates 

tho 

A/D  circuit,  a/ 

char 

VCO.'lt 

/a 

Bit 

2 

- 

desisrtatas 

tho 

VCO.  a/ 

char 

ssdrtlt 

/a 

Bit 

1 

- 

dasi{r>atas 

tho 

SSDR.  a/ 

char 

ralays_on:l| 

/a 

Bit 

0 

- 

1  to  turn  relays  an> 

»/ 

*/ 


0  otharwisa.  */ 


ii 


/*  This  structura  dascribas  data  storad  in  psga  zaro  of  tha  controllar's 
bubbla  mainory.  •/ 

struct  pagaOdata  {  A  tamplata  for  data  in  paga  zaro  of  tha 

controllar's  bubbla  mamory.  »/ 
char  swaapstartadi  /*  FALSE  if  swaap  not  yat  bagun. 

TRUE  if  swaap  has  baan  startad  onca.  a/ 
char  launchdonav  /*  FALSE  if  latr^ch  has  not  yat  n  datactad. 

TRUE  if  launch  has  baan  uaiectad.  »/ 
int  pagai  /a  Numbar  of  naxt  paga  avai labia  for 

log  data.*/ 

char  halfpagat  /a  0  if  top  half  of  naxt  availabla  paga  is 

ampty>  1  otharwisa.  a/ 

char  full_axparimant(  /a  TRUE  if  tha  full  axparimant  is  to  ba  parformad> 

FALSE  otharwisa.  a/ 

/a  We  need  to  record  tha  data  and  time  when  RECORD 
mode  was  last  initiated  if  wa  are  not  performing 
tha  full  axparimant.  a/ 
struct  datetima  RECORD_start_tiina> 


}» 


/*  This  structure  dascribas  data  storad  in  every  block  of  a  paga  in 
the  controllar's 

bubbla  memoryt  with  the  exception  of  paga  zero,  a/ 
struct  log_data  <  /a  A  tamplate  for  logged  data,  a/ 

struct  datetima  clock |  /a  Tima  and  data  of  recorded  data,  a/ 
char  evanti  /a  a  coded  event.  See  Bdefina  section  for 

codas,  a/ 

char  atodlADPOINTSl)  /a  Coded  A/0  readings.  Codes  not  yat  dafinad.  a/ 

>» 

/a  This  structure  has  BL0CKS_PEI(_PA6C  logLdata  structures  in  it.  a/ 
struct  full_log_paga  < 

struct  log_data  half_paga(BL0CKS_PER_PA6E)» 

>1 
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•num  pwr_cm4_ioodif  i«rs  C/k  Th«*«  codas  can  ba  givan  to  cmdlogl  )  for  »/ 
issuad  3  Ot  /a  procassing.  Thay  show  whathar  a  powar  raXay 

succaadad  «  1>  /»  command  was  maraly  issuad*  or  succaadad  or  a/ 

failad  =2  /a  faiXad. 

}> 


a/ 

a/ 


E.  FILENAME  BUBBLE.H 


/a  This  fiXa  contains  gXobal  prototypa  dacXarations  for  tha  functions  in 
'■bubbla.e”.  a/ 


axtam  void 
axtam  void 
axtam  char 
axtam  char 
axtam  void 
axtam  char 
extern  void 
extern  char 
extern  void 
extern  void 
extern  void 


bpagasatt int  pagaJt 
bubcmdmanu( void ) t 
bubinitlvoidlt 

bubiolchar  cofflmand>int  paga>char  abuffar)) 

bubmanuC  void ) ) 

bub_on(void)t 

bub_off(voidM 

issububcmdC char  command)) 

rdstatregf  void ) ) 

showbchbufftchar  buffer!  1  >char  mode)) 
tastpat tern (char  buffer! 1 )) 


F,  FILENAME  BUBBLE.C 

/a  bubbXa.c  a/ 

SincXude  "bubrw.h" 
ffincXude  "vibro.h" 

SincXuda  "convert. h" 
ffincXuda  "expmnt.h" 

DincXude  "inout.h" 
aincXuda  "deXay.h" 
ffincXuda  "newio.h" 
bincXuda  "gXobaX.h" 

void  bpagasat! int  page)) 
void  bubcmdmenut void ) ) 
char  btiiinit(void)> 

char  bubiolchar  command* int  paga*char  abuffar)) 
void  bubmanul void)) 

char  bub_on(void))  /a  turn  on  powar  to  'ttta  btiibla  card  a/ 

void  b(ib_off(void))  /a  turn  off  tha  power  to  tha  biiibXa  card  a/ 

char  issubUbemdl char  command)) 
void  rdstatragivoid)) 

void  showbubbuffichar  buffar!  ]*ohar  mode))  /a  display  tha  biJibXa  buffer,  a/ 
void  tastpattamfohar  buffer!!))  /a  sets  whole  bubble 

buffar  to  character  of  users  ohoicaa/ 


. . . . . 

/a  Sea  tha  bubble  memory  manual  regarding  tha  setting  of  tfia  parametric 
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rssistarst  which  is  what  this  function  doas.  »/ 
void  bpagasatf int  paga ) 

< 

output( BUBCTRL>BLDPARH ) I  /»  signal  to  BMC  naxt  5  bytas  to  data  port 

ara  tor  paramatric  ragistars  */ 
output!  BUBDATAtOxCD)  /*  ona  paga  to  transfar  BLR_LS8  */ 
output!  BUBOATA>OxlO)>  /*  ona  FSA  chamal  BLR_HS8  */ 
output! BUBDATAtOxZO  ) )  /*  Enabla  ragistar-anabla  raad  corractad  data  */ 

/*  Mask  off  lowar  byta  of  paga  number.  */ 
output!  BUBO  AT  A  >  paga  li  OxOOffli 

/*  Mask  off  higher  byta  of  page  number*  with  a  zero  MBM.  »/ 
output!BUBDATA,!paga  »  8)  k  OxOOlfll 

) 


/*  Select  from  a  manu*  and  issue*  a  command  to  the  bubble  memory.  */ 
void  bubcmdmenu! void ) 

< 

char  data( 

static  int  commandC  1  =  < 

BABORT,  BLOPARM,  BINIT,  BFI FORESET* 

NULL,  BWRBLREG 

)» 

while  !TRUE  )( 

printf!  "Select  a  command  to  be  issued  to  the  bubble  memory;  nr 
A  Abort  B  Load  paramatric  registers  C  Initialize  D  FIFO  Reset  n  r 
E  Transfer  40  bytes  of  Oxff. 

Z  Return  to  previous  menu.  nr")» 
data  -  tolowerl termini  III 
printf! "Xc  n  r"  ,data  ) ! 

if  Idata  ==  'z' I  returns 


F  Write  boot loop  register  n  r 


/*  Issue  bubble  transfer  command.  »/ 
if  ! data  ==  'a '  )  t 
if  ! bubxfer!  I  ) 

printf I "Transfer  succeeded .  n  r" ) > 

else 

printf I "Transfer  failed,  n  r" I > 
continual 

) 

/»  Initialize  paramatric  registers  for  paga  zero  */ 
if  !data  ==  'b' )  < 
bpagesat! 0 )| 
continual 

) 


/*  Check  for  other  valid  responses  */ 
if  Idata  <  'a'  | |  data  >  'f • )  < 

printf! "Use  a  valid  latter  please,  n  r"  )i 
continual 

) 

/«  Issue  the  command  indexed  by  the  letter  •/ 
if  I issububemd! commandidata- 'a ’  ] )  I 
printf !  "Command  succeeded.  nr")i 
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•Is* 


> 


> 


printf ( "Conmand  failed,  n  r" 


/»  This  routine  initializes  the  controller  card's  bubble  memory. 

Return  FALSE  if  unsuccassfult  TRUE  otherwise. 

After  power  is  applied  to  the  bubble  meraory>  call  this  routine. 

It  implements  the  flow  chart  on  pp.  4. 9-4. 9b  in  BPK  5V7SA  Protyping  Kit 
User's  Haual  from  Intel.  */ 
char  bubiniti void) 


t 


/*  Clear  the  bubble  memory  registers.  */ 
if  ( ! issububcmdt  BABORT ) )  < 


) 


printf  (  "ABORT  command  failed,  nr"  )t 
returnl FALSE ) i 

) 

delay(BUBDELAY)j  /«  Delay  BUBOELAY  *  10  ms  »/ 

bpagesetlO)t  Load  the  parametric  registers  of 

the  bubble  memory.  */ 

if  I  * issububcmd( BINIT  ) )  {  /*  Initialize  bubble  memory  for  use.  */ 

printf  I  "INITIALIZE  command  failed.  nr")( 
returnl FALSE ) > 

1 

if  1 ?issububcmd(BFIFOR£SET ) )  C  /*  Reset  FIFO  buffer.  */ 
printf!  "FIFO  RESET  conmand  failed  in  bubiniti  I.  nr")> 
return! FALSE  )) 

) 

if  ( Jbubxferl  ))  {  /»  Write  40  Oxff  characters  to  the 

bubble  memory  controller.  */ 
printfl"40  byte  transfer  failed.  Status;  ")j 
rdstatregl  )i 
returnl FALSE  ) ) 

) 

if  ( !issububcmdlBWRBLREGI )  /*  Put  boot  loop  memory  nap  into  BMC.  */ 

return! FALSE  1 i 

retumlTRUE))  /*  If  you  got  this  far.  everything 

worKed.  */ 


/*  Perform  normal  input  from  or  output  to  the  bubble  memory 
controller,  a/ 

char  bubiolchar  commaixl.int  page.char  abuffer) 

/a  "command"  can  be  BREAD  to  read>  BHRITE  to  write.  */ 

/a  "page"  is  a  b<.Mle  memory  page  number,  from  0  to  8192.  •/ 

/a  "buffer"  is  a  pointer  to  •  buffer  of  length  PAGELENGTH.  a/ 

< 

int  j»  /a  Counters,  a/ 

/a  Do  not  operate  the  bubble  memory  if  the  temperature  is  below 
MIN_OPERATING_TEMP.  a/ 
if  ( colder_thanl M1N_0PERATING_TEMP  ) ) 
returnl FALSE ) > 
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bub_onl  )) 
if  ( !bubinitl ) )  < 
bijb_offl  )j 
ra turn I  FALSE  )> 

} 

bpagasat(paga)>  /»  Sat  paranatric  ragistara  for  tha  dasirad  paga.  »/ 
if  Icofflmand  BREAD)  < 
bubraad) buf far ) i 
)  alsa  if  (coimiand  ==  BHRITE )  { 
bubwrita) buf far ) I 

) 

/»  Nait  for  tha  BHC  to  finiah  anptying  tha  FIFO  buffar  and  ratum 
OPCOHPLETE.  »/ 
for  ( j=Ojj<BTRIESj+*j)  { 

if  (ir^t(BUBCTRL)  t  BOPCOMPLETE ) 
braaK i 

) 

if  ( j  >=  BTRIES)  { 
bub_off  (  ) k 

printfl "Couldn't  gat  an  OPCOHPLETE  from  BMC.  Status:  ")k 
rdstatregl  )> 
roturn( FALSE ) k 

1 

bub_of f (  )  k 

/*  printfl  "OPCOMPLETE  racaivad  from  BMC.  nr")k  «/ 

returnl TRUE  ) k  /*  If  you  got  this  far»  the  I/O  worked!  •*/ 

} 

void  bubmanulvoid) 

< 

char  datak 

static  char  success!  1  s  < 

"Bubble  was  successfully  initialized  in  bubmamul  ).  nr" 

Ik 

static  char  failure!  1  =  < 

"Bubble  couldn't  be  initialized  in  bubmenut  ).  nr" 

)k 

while  (TRUE)  < 
printfl 

"A  Turn  bubble  memory  power  on.  n  r; 

B  Turn  bubble  memory  power  off.  n  r. 

C  Initialize  bubble  memory  for  use  (fully  automatic ) n  r, 

Be  sura  to  turn  the  bubble  memory  power  on>  first., nr', 

0  Issue  one  of  a  menu  of  commands  to  the  bubble  memory. ,n,r\ 

E  Enter  data  from  Keyboard  into  buffer,  n  r; 

F  Show  buffar  contents  in  ASCII  format. n  r\ 

G  Show  buffer  contents  in  hexadecimal  format. 'n  r\ 

H  Copy  buffer  contents  to  bubble  memory  (write  bubble  memory ).  n  r, 

I  Copy  contents  of  bubble  memory  to  buffer  ( read  bubble  memory ) .  ,n  r , 

J  Display  contents  of  bubble  memory  status  register,  n.r', 

Z  Ratum  to  pr'evious  menu.  n,r")k 

data  s  tolowerl termini ))k 
printfl "/c  n  r" >data ) k 
switch!  data  )< 
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e«s*  ' • ' : 

bub_onl  )i 
br«aR> 
cas0  'b': 

bub_off(  )» 
brsaK  > 
cas«  'c': 

if  (bubinifC  ) ) 

printf ( aucoiss ) i 

pr intf ( failur* ) i 
broaKt 
casa  'd': 

bubcmcbianuC  )| 
braaki 
casa  'a': 

fastpattamC  fanpbuffarU 
break) 
casa  ' f ' : 

st-towbubbuf f  ( tempbuf far, ASCII )) 
break ) 
case  ' g ' : 

showbubbuf f( fanpbuf fer,HEX)l 
break) 
casa  'h': 

if  (  {bubioIBWRITEige'tpaganol  ) >fempbuffer ) ) 
printfC'Hrifa  Failed.  nr"») 
break ) 
case  ‘ i ' : 

if  ( 'bubiot BREAD  tgefpagenol  )>'taiiipbuffer  I ) 
prinff  (  "Read  Failed,  nr")) 
break ) 
case  ' j ' ; 

rd$'tatreg(  )) 
break) 

case  'z‘:  case  'Z't 
return) 
default; 

printf  (  "Use  a  valid  letter^  please,  nr")) 


char  bub_on(void)  /»  turn  on  poMer  to  the  bubble  card  •/ 

< 

output) BCLRC2 iBUBRSr ))  /*  Apply  a  reset  to  the  bubble  meisory.*/ 

output! BSETC2>BUBPHR))  /•  Apply  poner  to  the  bubble  memory.*/ 

/•  The  following  delays  could  bo  100  *is  I  according  to  the  bubble 
doojnentation)  but  did  not  work*  so  we  used  300  ms.  «/ 
delaylBUBOELAY))  /•  Hait  BUBDELAY  •  10  ms  for  a  response.  •/ 

output(BSETCZ*BUBRST ))  /*  Remove  reset  signal.  */ 

delay) BUBOELAY  ))  /•  Hait  BUBDELAY  •  10  ms  for  a  response.  «/ 
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void  bub.off (void)  /*  turn  off  tha  powar  to  tha  bubble  card  «/ 

< 

issububond) B ABORT )  t  /*  Issue  the  "abort"  command  to  tha  bubble  card.  »/ 
output! BCLRC2 iBlBRST ))  /»  Apply  a  reset  signal  to  tha  bubble  memory 

before  switching  the  power  off. 

delay) BUBOE LAY  )>  /»  Hait  BUBOELAY  e  10  ms  for  a  response,  a/ 

output) BCLRC2>BUBPHR) I  /»  Remove  power  from  the  bU>ble  memory,  a/ 

) 


/a  Issue  a  command  to  the  bubble  memory  controller,  a/ 
char  issububcmd) char  command) 

{ 

int  i) 

char  status) 

i=0)  /a  Initialize  this  so  it  has  a  value  even  if  BABORT 
is  the  command,  a/ 

/a  Don't  issue  a  command  until  the  BUSY  bit  goes  away.  «/ 
i f  ( command  ! =  BABORT  )  < 

for  (i=0)i  <  BTRIES)++i)  t 

if  ((  input) BUBCTRL  ) )  S  BBUSY) 


if  ( i  >=  BTRIES)  i 

printf) "Bubble  controller  stayed  busy  indefinitely  in  issububcmd)  ). 
Status:  ")) 

rdstatreg)  )) 
return) FALSE ) ) 

) 

output ( BUBCTRL  jcommand ) ) 

/a  Command  is  not  accepted  until  busy  bit  goes  to  one.  a/ 
for  ( i  =  0)i  <  BTRIES)  +  +  i  ){ 
status  *  input ( BUBCTRL )) 

if  ((status  S  BBUSY)  ||  (status  (  BOPCOMPLETE ) ) 
break) 

) 

/a  For  all  commands  except  RESET  FIFO  and  HRITE  BOOTLOOP  REGISTERS > 
you  must  get  a  BUSY  bit  to  consider  that  the  command  was  accepted. 
Howeverf  an  OPCOMPLETE  is  okay)  if  you  get  itr  proceed.  Note: 
this  is  not  the  way  the  documentation  says  to  do  this.  It  says 
you  must  got  BUSY  set  first.  However*  that  did-t't  seam  to  work.  */ 
if  ( ( i  >s  BTRIES) 

t<  (command  !=  BFIFORESET)  M  Iconwiand  !«  BtWBLREG) 

Ct  (  status  t  BOPCOMPLETE))  { 
printf ( "Bubble  command  Xsh  was  not  accepted.  Status:  "* 
ctoh) command ) ) ) 
rdstatreg) )) 
return) FALSE  )) 

) 

/a  Hait  for  tha  OPCOMPLETE  status  code.  »/ 
for  (i  «  0)i  <  BTRIES)>«i)< 

if  ( input) BUBCTRL)  t  BOPCOMPLETE) 
break ) 

} 

if  ( i  >*  BTRIES)  < 
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printf ( “OPCOMPLETE  fro*  BHC  rMv«r  occurred  for  cow—nd  Xsh.  Statu*: 

etohl  eeiMwnd ) )  t 
rd*tatr*g( )) 
roturni FALSE ) ( 

}  •!*•  < 

rotum(  TRUE )  | 

} 

> 

. . . 

void  rdstatrogtvoid) 

< 

printf  I  "X*  n  r'SctohC  ir*>ut(BUBCTRL) ) )» 

} 


void  shoMbubbuff I  char  buf fart ] >ehar  modal  /«  display  tha  bubbla  buffar. 
ASCII  format  trios  to  print  aach  charactar  as  if  it  Mara  a 
printabla  ASCII  charactar. 

HEX  format  is  tha  corract  option  to  usa  if  not  all  characters  ara 
printable.  »/ 

/*  Valid  values  for  "mode"  ara  ASCII  and  HEX  */ 


int  j)  /»  Dump  contents  in  an  8  by  8  array.  »/ 

tor  ( j=Olj<PAGELENGTHjj>+)  < 
if  (mode  ==  ASCII  I 

printf  (  "Xc"  .buf  fort  jilt 
else  < 

printfC'Xs  "»ctoh(buffort  jl  1 1| 
if  ( (0  »  (  j  4  II  X  81  It  (j  !=  Oil 
printfC  n  r" 

) 

) 

printfC  "  n  r"  1 1 


void  testpatterni char  buf fsrt ] I 

/»  sets  Mhole  bubbla  buffer  to  charactar  of  users  choice*/ 

< 

char  Cl 

char  stSTRLENli  /»  Storage  for  itoal  I.  «/ 

int  jl 


/»  Hake  sura  e  has  a  valua  before  chocking  its  contant*.*/ 
c  ■  •  O'l 

printff  "Specify  to  X*  character*  to  stuff  into  tha  bcMila.'n.r". 

itoa(PAGELEN6TH>*ll| 
for  I js0lj<PA6ELEN6THlj44l  < 
if  (c  !»  •  r' I  { 
c  >  termini  li 
if  (e  !*  ‘  r’  I  ’ 
buf fart*  Cl 
printf(''Xc"fCli 
1  also 

buffartj]  s  •  >1 
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buff«rtj]  =  •  •! 

} 

printfC  n,r")> 


G.  FILENAME  BUBRVV.H 

•xtam  char  bubxfarlvoid)! 

axtem  char  bubraadichar  abuffarli 

axtam  char  bubwritalchar  abuffar)t 


H.  FILENAME  BUBRW.S 

)  bubrw.s 

ndefine  TRUE  Oxff 

ffdefina  FALSE  0x00 

t  The  defini'tions  which  follow  are  from  the  file  "vibro  confrlr  headers  bnic.h" . 
t  Since  they  are  used  by  C  source  code>  they  are  incompatible  with  assembly 
I  coda.  Thus  they  are  copied  here  and  all  C  comments  have  been  converted 
)  to  assembly  language  comments. 

ttdefine  BUBDATA  0x40  (  I/O  port  for  the  controller's  bubble  memory.  */ 

ffdefine  BUBCTRL  0x41  l  Control  and  status  port  for  the  BMC.  */ 

)  The  following  codes  are  commands  to  the  bubble  memory  controller.  */ 

Pdefino  BA80RT  0x19 

Pdefine  BINIT  0x11 

ffdefine  BFIFORESET  OxlD 

Rdefine  BHRBLREG  0x16  »  Nrita  boot  loop  register.  */ 

edefina  BREAD  0x12 

ttdefine  BHRITE  0x13 

Pdafine  BLOPARM  OxOb  >  Load  parametric  registers.  •/ 

tdefine  BTRIES  30000  (  Bubble  commands  should  be  written  this  •/ 

»  many  times  before  giving  up  in  disgust.  */ 

)  The  following  are  bubble  memory  controller  status  codes.  •/ 
edefine  B8USY  0x80 

edefine  BOPCOMPLETE  0x40 

edefine  BFAIL  0x20 

edefine  BTIMING  0x02 

ffdefine  BFIFO  0x01 

edefine  B6USYBIT  7  I  These  constants  specify  which  bit  in  the  •/ 

Kdefine  BOPCOMPLETEBZT  6  >  BMC  status  bit  is  used  for  which  purpose.  •/ 

edefine  BFAILBIT  5 

edefine  BFIFOBIT  0 

Bdefine  BNEVER.REAOY  0 

ttdefine  BXFER.GOOO  1 

Bdefine  BXFER.BAO  2 

Bdefine  PAGE LENGTH  64  i  The  number  of  bytes  in  a  page  of  bubble  memory.  •/ 

Bdefine  MAXPAGE  8191  t  Greatest  valid  btiible  memory  page  nunber.  •/ 
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(ImplMMn't  in  ascmbly  cod*  a  C  routin*  to  pamit  a  vary  rapid  transfar 
)of  forty  bytas  of  Oxff  to  tha  biisbl*  manory  controllar  during  its 
> initialization, 
ichar  bubxf*r( void) 

axport  btitxfar 
region  coda 
bubxfar; 

push  ix 

id  ix>0  )  ix  < —  sp 

add  ix>sp 
(Issua  a  FIFO  RESET  command 

Id  a.FBFIFORESET  }  FIFO  RESET  command  cod*, 

out  l$BUBCTRL)>a 

Id  doiOxffff  I  Initialize  a  timeout  counter. 

fifors_busy:  I  Sea  if  tha  command  was  accepted, 

in  a,(«BUBCTRL) 

rla  (  Move  busy  bit  into  carry  flag, 

jp  c>f iforst_accapt*d  }  The  busy  bit  is  a  1  if  tha  command 

)  was  accepted. 

dec  da 

xor  a  t  Clear  register  a. 

or  d  t  See  if  de  is  0. 

or  a 

jp  nz»fifors_busy  t  Check  for  busy  bit  again>  since  timeout 

(  not  yet  complete. 

Id  aitFALSE  )  Timed  out  without  succeeding^  so 

jp  bxfar.exit  )  return  with  a  FALSE  condition  cod*, 

f i f ors  t.accep  ted : 

Id  b>40  )  He  need  to  transfer  40  bytes  of  Oxff 

Id  a>0xff 

xfer:  out  ($BUB0ATA),a 

djnz  xfer 

in  a , ( FBUBCTRL  ) 

I  The  transfer  succeeded  if  you  got  an  Op  Complete  code 
i  with  tha  FIFO  bit  sati  even  with  tha  timing  bit  (bit  1)  set. 
and  FBTIMIN6  (  Zeroize  the  timing  bit. 

cp  FBOPCOMPLETE  |  FBFIFO  i  Oo  we  have  operation  complete? 

jp  z»xfor_ok  )  Yes. 

Id  aiFFALSE  )  Unsuccessful  transfer, 

jp  bxfar.exit 

xf*r_ok: 

Id  a>FTRUE  )  Successful  transfer. 

bxf*r_*xit: 

pop  ix 

rat 

») 

tloplamant  in  assembly  cod*  a  C  routine  to  permit  vary  rapid  input  of 
ta  page  of  data  from  tha  biitbl*  memory, 
ichar  bubraad(char  abuffar) 

)< 

axport  bubraad 

import  issububemd 
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r*gion  coda 
bubrsad : 


Itoommant 

Registar  usaga: 


a  Scratch  spaca. 

be  Constant  1  for  subtractions. 

da  Constant  PAGELENGTH. 

hi  Constant  BTRIES 

be'  char  abuffar 

Randcowmant 

push 

ix 

Id 

ix>0 

»  ix  <"  sp 

add 

ix>sp 

axx 

t  Accass  altamata  ragistars. 

push 

be 

t  Sava  be* 

Id 

Cf  ( ix+4) 

1  be'  < —  char  abuffar 

Id 

b>(  ix+5 ) 

exx 

1  Return  to  primary  registers. 

Id 

hl.SBFIFORESET 

(  Issue  the  FIFO  Reset  command  to  the  BMC. 

push 

hi 

call 

issubUicffld 

pop 

hi 

cp 

SFALSE 

iQuit  if  this  comma,  d  didn't  work. 

jp 

nztf rok 

Id 

a,$BXFER_BAO 

jp 

exit 

frok: 

Id 

a,«BREA0 

i  Issue  the  READ  command  to  the  BMC . 

out 

( $BUBCTRL l,a 

Id 

hl,$BTRIES-l 

t  Look  for  BUSY  bit  up  to  BTRIES  times. 

Id 

bc>l 

{  Used  for  subsec^uent  decrements. 

raad_status: 

in 

a,(SBUBCTRL) 

i  Get  status  from  BMC. 

bit 

SBBUSYBIT.a 

(  Mas  the  command  accepted? 

jr 

nztraad 

>  Yes,  so  raad  a  block  of  data. 

bit 

$BOPCOHPLETEBIT,a 

)  Not  busy.  Has  operation  complete? 

jr 

nz tread 

)  Yes,  so  read  a  block  of  data. 

bit 

$BFAILBIT,a 

>  Not  busy,  not  done.  Failed? 

jr 

nzttimeoutl 

(  Didn't  fail.  Don't  know  why.  Allow  a 

Id 

at$BNEVER_REAOY 

i  timeout. 

>  Did  fail,  so  quit.  Return  function 

jp 

axit 

>  completion  coda  in  registar  a. 

timaoutl: 

OP 

a 

1  Reset  the  CARRY  flag. 

sbe 

hi, be 

(  Hava  wa  looked  for  a  BUSY  signal  BTRIES 

jr 

nc  ,raad_status 

1  times  yet? 

»  No,  so  try  again. 

Id 

a,ABNEVER_REAOy 

>  Yes,  so  wa  timed  out.  Quit  and  return 

jp 

axit 

t  function  completion  coda  in  register  a. 

raad: 

Id 

da,fPAGELENGTH-l 

»  Prepare  to  raad  PAGELENGTH  bytas  from  BMC 

raad.byta; 

Id 

hl,*BTRIES-l 

1  Prepare  to  check  FIFO  bit  BTRIES  times. 

chack_f ifo: 

in 

a,l  tBUBCTRL) 

1  Get  status  byte  from  BMC. 

bit 

$BFIF08IT,a 

i  Is  the  FIFO  bit  set,  i.a.  FIFO  ready? 
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jr 

nz>gatbyta 

>  Yes.  so  read  a  byta. 

or 

a 

>  Reset  the  CARRY  flag. 

sbc 

hltbe 

»  No.  so  try  again  up  to  BTRIES  times. 

jf 

ne>ch«cK_f ifo 

Id 

a>$BXFER_BAD 

t  Navar  got  a  FIFO  ready,  so  quit. 

jP 

•xit 

gotbyt*; 

in 

•  >((B(JBOATA) 

1  Read  a  byta  from  tha  BMC. 

•>o< 

Id 

(bc)>a 

1  Place  tha  byta  in  tha  buffer. 

inc 

be 

t  Point  to  tha  next  position  in  tha  buffer. 

•>o< 

or 

a 

i  Rasat  tha  CARRY  flag. 

•X 

da  .hi 

t  Put  eontants  of  da  in  hi  to  permit  use  of 

sbe 

hi  .be 

(  Hava  wa  read  all  tha  bytes  yat? 

•X 

da.hl 

l  Rastora  usual  contents  to  da  and  hi. 

jr 

nc.raad_byta 

(  No.  so  gat  another  one. 

Id 

a.$BXFER_GOOD 

t  Yes.  so  cajit.  Return  function  completion 

i  coda 

in  ragistar  a. 

•xit: 

•XX 

pop 

be  (  Rastora  altarnata  ragistars. 

•XX 

pop 

ix  (  Rastora  ix  ragistar. 

rot 

t) 

tlmplmnont 

in  assembly  coda 

a  C  routine  to  permit  vary  rapid  output  of 

>•  pag*  of 

data  to  tha  bti>bla  namory. 

ichar  bubwrit«(char  »buff«r) 

•xport 

bubwrita 

import 

issububemd 

ragion 

coda 

bubnrito: 

Pcommant 

Rogistar  usaga: 

a  Scratch  space. 

be  Constant  1 

for  subtractions. 

da  Constant  PAGE LENGTH. 

hi  Constant  BTRIES 

be'  char  *»buffer. 

bondconmant 

push 

ix 

Id 

ix.O 

»  ix  <"  sp 

add 

ix.sp 

•XX 

1  Access  altarnata  ragistars. 

push 

be 

t  Sava  be* 

Id 

e.l  ix44) 

»  be*  < —  char  afauffar 

Id 

b.(  ix*5) 

•XX 

1  Return  to  primary  ragistars. 

Id 

hl.ABFIFORESET 

1  Issua  tha  FIFO  Rasat  command  to  tha  BMC. 

push 

hi 

call 

issububemd 

pop 

hi 

cp 

AFALSE 

(Quit  if  this  command  didn't  work. 
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3P  • 

■frokZ; 

Id  a 

out  I 

Id  h 

Id  b 

writ*_status: 


nzitroRZ 

a,$BXFER_BAD 

•xitZ 

a>$BHRITE 

l$BUBCTRL)>a 

hl,$BTRIES>l 

bCf  1 


JP 

timaoutZ: 


a>l«BUBCTRLl 

$BBUSYBIT,a 

nz  twrita 

tBOPCOMPLETEBIT,! 

nztwrita 

$BFAILBIT>a 

nzitimaoutZ 

a,$BNEVER_READY 

axitZ 


nc  iwr i ta_s  ta  tus 
a,$BNEVER_READY 


I  Issua  tha  HRITE  command  to  tha  BMC. 

>  LooK  tor  BUSY  bit  up  to  BTRIES  timaa. 

(  Usad  tor  aUbaaquant  dacraawnta. 

I  Gat  atatua  trom  BMC. 

I  Haa  tha  command  accaptad? 

I  Yaai  ao  writa  a  block  ot  data. 

I  t  Not  buay.  Naa  operation  complata? 

(  Yaa>  ao  writa  a  block  ot  data. 

I  Not  buay>  not  dona.  Failad? 

I  Oicki’t  tail.  Don't  know  why.  Allow  a 

>  timaout. 

k  Did  tailt  ao  quit.  Raturn  tunction 
i  completion  coda  in  ragiatar  a. 

I  Raaat  tha  CARRY  tlag. 

t  Hava  wa  looked  for  a  BUSY  signal  BTRIES 
I  timaa  yat? 
k  No>  ao  try  again. 

k  Yes>  ao  wa  timed  out.  Quit  and  return 
k  function  completion  code  in  register  a. 


JP 

writa: 

Id 

writa_byta: 

Id 

chack_titoZ: 


de,$PAGELEN6TH-l  k  Prepare  to  write  PAGELENGTH  bytes  to  BMC. 


JP 

putbyte: 


hl,«BTRIES-l 

a , ( «BUBCTRL  ) 
$BFlFOBIT,a 
nzipu tbyte 

a 

hltbc 

nc I check_t i toZ 

a,$BXFER_BAO 

exit 


k  Prepare  to  check  FIFO  bit  BTRIES  times. 

k  Get  status  byte  trom  BMC. 
k  Is  tha  FIFO  bit  set>  i.e.  FIFO  ready? 
k  Yes>  so  read  a  byte, 
k  Reset  the  CARRY  flag, 
k  No>  so  try  again  up  to  BTRIES  times. 

k  Never  got  a  FIFO  ready >  so  quit. 


a>(bc)  k  Gat  tha  byta  from  tha  buffer. 

($BUBOATAI«a  k  Write  a  byta  to  tha  BMC. 

be  k  Point  to  tha  naxt  position  in  tha  buffar. 

a  k  Raaat  tha  CARRY  flag. 

da>hl  k  Put  da  into  hi  to  permit  uaa  of  sbc. 

hl>bc  k  Hava  kxa  read  all  tha  bytes  yat? 

da«hl  k  Restore  usual  contants  to  da  and  hi 

nc>write_byta  k  No>  so  gat  another  one. 

a>tBXFER_GOOO  k  Yes>  so  quit.  Return  function  completion 
k  coda  in  register  a. 


axitZ: 


k  Restore  altamata  registers. 
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pop  ix  (  Rostorp  ix  rpgisipr. 

rpt 


>} 


1.  FILENAME  CLOCK.H 


/»  This  fils  contsins  pxtpmal  prototypins  daclarstions  of  all  functions  usad 
in  "clock. c".  */ 


axtam 

axtem 

axtam 

axtam 

axtam 


axtam 

extern 

extern 

extern 

extern 


void  clocKintI struct  datetima  »clock>struct  idatatima  »iclock)t 
void  clockreadi struct  datatima  *your_clock ) > 

char  clockconpara( struct  idatatima  aclockltstruct  idatatima  •clockZ)i 
void  clocksetl  struct  datetima  adockjl 
void  clocksum( struct  idatatima  »rasult> 
struct  idatatima  ttclocklt 
struct  idatatima  »clock2)( 
void  dunip_clock(  struct  datatima  *clock)i 
void  rtc(void)> 

void  shoM_Maketimel struct  idatatima  owaketima)) 

void  testtimaout( void )  k 

char  timeout! int  delay time  tint  measure)( 


J.  FILENAME  CLOCK,C 

/»  clock. c  •/ 

Sincluda  "vibro.h" 

^include  "convert. h" 

^include  "inout.h" 
aincludo  "newio.h" 

^include  "global. h" 

void  clockinti struct  datetime  •clockistruct  idatetime  *iclockl> 
void  clockread! struct  datetime  *your_clock H 

char  clockcomparel struct  idatetime  »clocKl>struct  idatetime  «clocK2)) 
void  clocksetl  struct  datetime  «clockU 
void  clocksumi struct  idatetime  «result> 

struct  idatetime  *clocklr 
struct  idatatima  •clock2)> 
void  dump.clocki struct  datatima  sclock)) 
void  ckanp.iclocki  struct  idatatima  sclock)) 
void  gat.timel  struct  datetima  »data_and_tima 
void  rtclvoidli 

void  show_wakatima( struct  idatatima  «v«akatimali 

char  astrcpylchar  *sl»  char  *s2)» 

void  tasttimaoutl void ) I 

char  timeout! int  dalaytimaiint  measure)) 

static  char  amonthst 1  ■  { 

"**  Invalid  month  **", "January" ."February" ."March", "April" , "May" ,"J(.»)a" , 
"July" . " Au^js t " . "Saptambar" . "October" . "Novambar" . "December" 

J) 
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/»  Convart  a  daiatima  structura  to  an  idatatima  aquivalant.  This  allows 
arithnatic  to  ba  parformad  on  datas  and  tiraas.  */ 
void  clocKint( struct  datatima  »clocKtstruct  idatatima  »iclock) 

< 


iclocK->imonth 

iclocK->idate 

iclock->ihour 

iclocK->iminuta 

iclock->isecond 


=  bcd_int(clocK->manthU 
=  bcd_int(clocK->data)( 

=  bcd_int( clock->hour )| 

=  bcd_intl clocK->fflinuta) ( 

=  bcd_ inti  clock- >sacond U 
iclocK->ihundradths  =  bcd_int(  clocK->(xndradths )  ( 
iclock->i thousandths  =  bcd_int(clock->thousandths  )( 


/)HHHnnnHnn>iHnnnHnnnHHHHt»<nHnnHHHH>  iiiiimMMmimoiiimiiwmmsKmilciiimmi  >hhhhhhk»»«»«/ 
/•  This  routina  fills  a  clock  structura  with  tha  currant  data  and  time.  »/ 

/*  It  will  not  worry  about  the  hundredths  and  thousandths*  but  it  will  attempt 
to  ensure  that  at  least  tha  seconds  have  not  changed  between  the  first 
and  the  last  reads  of  the  various  clock  registers.  Thus  the  hundredths 
and  thousandths  should  not  ba  regarded  as  accurate*  ever.  */ 
void  clockreadi struct  datatima  *your_clock  I 
< 

int  i  i 

i  =  Oi 
do  < 

your_clock->thousandths  =  input  I  THOUSANDTHS  )  > 
your_clock->hundredths  =  input! HUNDREDTHS U 
your_clock->second  =  input! SECONDS U 

your_clock->minute  =  input! MINUTES )> 

your_clock->hour  =  input! HOURS  I  > 
your_clock->date  =  inputlDATE)» 
your_clock->nonth  =  input! MONTH  I > 

)  while  !your_clock->second  !=  input!  SECONDS  I  tt  ♦■fi  <=  10  »  TRIES)! 

) 


/******»»»**«***«»)HHHMHHt**»«»**««**«******»«*)H»»*)HHt****»****«»**********«J»/ 
/»  Compare  two  clock  times.  Return  TRUE  if  the  first  is  later  than  or 
equal  to  tha  second*  FALSE  otherwise.  This  routina  ignores  the 
hundredths  and  thousandths*  since  they  are  inaccurate.  */ 
char  clockcomparel  struct  idatatima  aclockl*struct  idatatima  !»clockZ  ) 

int  difference I 

difference  *  clockl->imonth  -  clockZ->imonth> 

/»  This  logic  allows  you  to  decide  January  comes  after  December.  */ 
if  !! difference  *  IZ)  X  IZ  <  6 

tt  difference  !-  0)  return! TRUE)! 
if  ! difference  !=  0)  return! FALSE  1 1 
if  !clockl->idate  <  clockZ->idate  I  return! FALSE 
if  !clockl->idate  >  clockZ->idate)  retumlTRUEti 
if  !clockl->ihour  <  clockZ->ihour  )  return! FALSE  ) ! 
if  ! clockl->ihour  >  clockZ->ihour  )  return! TRUE ( > 
if  ! clockl->iminute  <  clockZ->iminute  I  return! FALSE  ) » 
if  ! clockl->iminute  >  clockZ->iminute )  retum!TRUE)> 
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if  (clocKl->is«cond  <  clocK2->is«cond)  r«furn( FALSE ) ( 


p«tumtTRUE  )i 

> 


/*  This  roufins  sets  the  reel  tine  clock.  »/ 
void  clockset( struct  datetime  eclocK) 

< 

get_time( clock ) » 
output(  MONTH  »clock->iiionth ) ) 
output! DATE  >clock->date )l 
output! HOURS. clock->hour ) ) 
output!  MINUTES>clock->minute )t 
output! SECONDS>clock->second ) \ 

J 

/*  Find  the  sum  of  two  calendar  periods.  */ 
void  clocKsum! struct  idatetime  ^result. 

struct  idatetime  »clockl> 
struct  idatetime  «clock2 ) 
t 

int  maxdatei  /*  The  last  valid  date  in  the  month.  */ 

result->isecond  =  clockl->i second  +  clock2->isecond> 
result->ininute  =  result->isecond  /  60> 
result->isecond  X-  60 » 

result->iminute  ♦=  clockl->ininuto  ♦  clock2->iminuto> 
result->ihour  =  result->iminute  /  60 j 
result->iminute  60} 

result->ihour  ♦*  clockl->ihour  ♦  clock2->ihour } 
result->idate  =  result->ihour  /  24} 
result->ihour  /{=  24} 

result*>idate  ts  clockl->idate  t  clock2*>idate} 
result->imonth  =  1  +  ! clockl->inonth  ♦  clock2->inonth  -  11  /  12} 
maydate  =  ! I result->inonth  ==  4 )  ||  ! result- >inonth  ==  61 

II  1 result->imonth  *=91  ||  ! result->imonth  ==  11))  7  50  :  31} 

/«  The  real  time  clock  makes  no  provision  for  leap  year,  so  leap  years 
are  ignored  in  this  program  !sigh!)  */ 
maxdate  =  ! result->imonth  ==  2 )  ?  28  :  maxdate} 
result->imonth  ♦=  ! result->idate  -  1)  /  maxdate) 
result->idate  =  1>  ! rasult->idate  -  1)  X  maxdate} 
i-esult->imonth  =  1  ♦  !  result->imonth  -  1)  X  12} 

} 


/•  Print  a  clock  structure.  •/ 

void  Aanp.clock!  struct  datetime  aclock) 

< 

int  hour,  minute,  second,  date,  month} 

hour  ■  bcd_int!clock->hour  1} 

minute  =  bcd_int! clock->ninute  ) } 

second  =  bcd_int!clock->second)} 

date  =  bcd_int! clock->date  ) } 

month  =  bcd_int! clock->nonth  ) } 
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printf(''X02.2d:/;02.2d;X0Z.2d  '/.*  Xdn.r'S 
hour  >minu'ta , second) 
months!  month  >  12  ?  0  ;  month  ]> 
data 
)> 


/*  Print  »n  iclocK  structure.  */ 
void  dump_iclocK( struct  idatetime  «clocK ) 
< 


printtl"X02.2d:>'02.2diZ02.2d  Zs  '/.tlnr", 

clock->ihour,clock->iminute»clock->isecond» 
months!  clocK->imonth  >  12  ?  0  :  clocK->imonth  ]> 
clocK->idata 
)> 


void  get_tirie(  struct  datetime  *date_and_time ) 

{ 

int  month)  date)  hour)  minute >  second)  maxdatet 
static  char  or!  1  =  "nr") 

while  (TRUE)  { 

printf I "Month?  (1-12)  ")) 

month  *  getintl )) 
if  (month  >=  1  it  month  <=  12) 
break ) 

printf  (  "Invalid  month.  Re-enter  it.  nr")) 

J 

printf ( cr ) ) 

maxdate  *  (month  *®  4  | |  month  s*  6  | |  month  ®®  9  | 1  month  »®  11)  ? 
30  :  31) 

maxdate  -  (month  ®®  2)  ?  28  ;  maxdate) 
while  ( TRUE  )  < 

printfC'Day?  (1-Xd)  ’Smaxdate)) 
date  =  getint( )) 

if  (date  >=  1  ti  date  <=  maxdate) 
break ) 

printf ("  n  rinvalid  date.  Re-enter  it.. nr")) 

) 

printf(cr )) 
while  (TRUE)  < 

printf ("Hour?  (0-25)  ")) 

hour  ®  getint( )) 
if  (hour  >s  0  IS  hour  <«  23) 
break) 

printf(  "Invalid  hour .  Re-enter  it. '.nr'*)) 

) 

printf) cr)) 
while  (TRUE)  < 

printf)  "Minute?  (0-59)  ")) 

minute  ®  getint)  I) 
if  (minute  >®  0  IS  minute  <*  59) 
break ) 
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prlrctfC  "Invalid  minuia.  Ra-aniar  it.n.r")t 

) 


printf(cr  )j 
Mhila  (TRUE)  < 

printfC'Saoond?  (0-59)  “)> 

sacond  *  gaiint) )) 
if  (sacond  >•  0  tt  sacond  <>  59) 
braaK  > 

printf(  "Invalid  sacond.  Ra-aniar  it.\n\r”)) 

} 


ppin'tf(cr  )j 
da  ■la_and_  i  i  ma  -  >iiK>n  th 
da'to_and_'tiina->da'ta 
da  ta.and.f ima- >hour 
da'ts_and_f  ima->ininufa 
da'ta_and_'t  ima- >second 


=  inf.bcd) monih ) I 

-  in't_bcd(da'ta)> 

=  in't_bcd(hour  )> 

*  in't_bcd(ininu'ta)t 
=  inf.bcd) sacond)) 


} 

/»»•«««»«»««»««»»»»««»»«««•»«««»«»«•«««»««««•«««»»«««««««««•««»«»»««»«»«•«««/ 
/*  This  routine  is  a  menu-driven  collection  of  routines  for  testing  the 
clock  functions.  */ 
void  rtc(void) 

{ 

char  data) 

while  (TRUE)  < 
printf ( 

"  n  rReal  time  clock  functions,  n  r  n  r 
A  Read  Clock,  n  r 
B  Set  clock,  n  r 
C  Test  timeout)  )  function,  nr 
Z  Return  to  main  menu,  nr")) 

data  =  tolower) termin( ) ) ) 
printf)  "'/.c  n  r"  ^data  )> 
switch  (data)  i 
case  ' a ' : 

clockread( (clock  I ) 
dump_clock( (clock ) ) 
break) 
case  'b': 

clockset) (clock ) ) 
break) 
case  'c' : 

tasttimaout) )) 
break) 
case  ‘z'l 
return) 
default: 

printf)  "Use  a  valid  letter  please. \n\r" )) 
break) 

J 

) 

) 
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/*  This  routin*  displays  tha  waKa-up  tima.  */ 
void  show_waKatiiiia(  struct  idatatima  MwaKatima) 

char  siSTRLENlt  /*  String  tor  itoa(  )  routina.  »/ 

itoalNakatima->imonthtS 

printft  "Haka-tp  tima  is:  .n.rHonth  ■  ''>s)t 

i toa ( waka t ima- > ida ta f s ) I 

printf ( “Data  =  Zs  ",s)j 

itoa( wakatima->ihour is ) ( 

printf r'Hour  »  Zs  "tS)| 

itoa(  wakatima->iininutatS )  I 

printf ( "Minuta  =  Zs  “tsli 

i toa( Makatima->isacondtS ) ( 

printf  (  "Sacond  >  Zsnr">s)( 

} 

/*  This  routine  is  usad  to  test  tha  tinaoutf  )  function.  */ 
void  testtiineout( void) 

< 

char  data#  /*  A  character  antarad  from  tha  keyboard. 

units (  /*  Tha  units  of  delay.  */ 

int  delay)  /*  The  number  of  units  of  delay. 

while  (TRUE)  < 

printf ("Test  of  timeout( )  function,  n  r n  r 
Specify  tima  units  for  delay:  n  r  n  r. 

A  Hours  n  r 
B  Minutes  n  r 
C  Seconds  n  r 

Z  Return  to  previous  menu,  nr")) 

data  s  tolower(  termin(  ))) 
printf ( "Zc  n  r" idata I ) 
switch  (data)  < 
case  ' a ' : 

units  =  HOURS) 
break ) 
case  'b': 

\niU  >  MINUTES) 
break) 
case  'c': 

inits  *  SECONDS) 
break ) 
case  'z': 
return) 
break ) 
default: 

printf)  "Use  a  valid  latter  please. \n.r’' )) 
break) 

} 

printf  ("  n  rHow  many  units  of  delay  do  you  want?  nr")) 

delay  *  gatint)  )) 

printf)  "  n  rStarting  delay:  n  r"  ) ) 
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clocKrcadI tclocK ) i 
<hjmp_clock(  tclocK. )  l 
tim«out( d«lay >units ) » 

Mhila(  'tiniMutl NULL, NULL)  )t 
printft "Delay  conplate.  n  r")j 
ppintf("Xc",BELL)» 
clocKreadt (clock ) t 
duRip_clock(  (clock )  ( 


/*  This  routine  is  used  to  initiate  a  timeout  sequence,  and  to  test  tor 
completion.  To  sat  the  desired  delay  time,  the  parameter  "delay" 
should  be  non-zero.  To  test  tor  completion,  "delay"  should  be  zero  (NULL). 
Nhen  setting  the  delay  time,  the  tunction  always  returns  TRUE,  (then 
testing  tor  completion,  it  returns  TRUE  it  the  time  has  elapsed,  FALSE 
otherwise.  */ 

cl^r  timeout)  int  delaytime, int  measure) 

/»  "delaytime"  is  the  length  ot  the  timeout.  */ 

/*  "measure"  is  the  unit  ot  measure  ot  time.  This  can  be 
MONTH,  DATE,  HOURS,  MINUTES,  or  SECONDS.  */ 


static  struct  datetime  timenow) 

static  struct  idatetime  itimenow,  waittime> 


/*  Allow  the  user  to  interrupt  by  use  ot  CTRL  characters.  */ 
allow_ctrl_intarrupts(  )> 

clockreadt  (timenow)i 
clockinti (timenow, (itimenow ) ( 

it  (delaytime  ==  NULL)  <  /»  It  delaytime  ==  NULL,  then  check  to 
see  it  timeout  period  is  over.  »/ 
return) clockcomparal (i timenow ,(wake time  ) ) v 
1  else  <  /*  Otherwise,  sat  the  wakaup  time.  */ 

waittime. imonth  -  waittime. idate  =  waittime. ihour 
=  waittima. iminute  -  waittime. isecond  =  0) 
switch) measure )  < 
case  MONTH: 

waittime. imonth  =  delaytima) 
break  > 
case  DATE: 

waittima. idate  >  dalaytimei 
break ( 
case  HOURS: 

waittima. ihour  *  dalaytima) 
break) 

case  MINUTES: 

waittime. iminute  *  dalaytimei 
break! 

case  SECONDS; 

waittime. isecond  ■  dalaytimei 
break! 

1 

clocksum) (waketime, (itimenow, (waittime)i 
show_waket ima) (waket ime )  i 
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r«tum(TRUE)» 

> 

} 


K.  FILENAME  CONVERT.H 

/*  This  fil*  contains  axtamal  prototyping  daclarations  for  all  functions 
in  "convart.c".  */ 

axtam  char  atoh(char  aasciili 

axtem  unsignad  int  atohexint(char  asciiCDi 

axtam  int  atoiCchar  as)t 

axtam  char  abcd_asc(  char  bcd)t 

axtam  int  bcd_int(char  bed)) 

axtam  char  actoh(  char  by ta )  t 

axtam  char  int_bcdl  int  dacimaDi 

axtam  char  »itoa(  int  n>  char  sCDt 

axtam  char  tolowar)  int  c)) 

axtam  char  »uitohl  unsigned  int  word)) 


L.  FILENAME  CONVERT.C 

/»  convart.c  •/ 

^include  "vibro.h" 

R include  "inout.h" 
ttincluda  "global. h" 

char  atoh(char  »ascii)) 

unsigned  int  atohaxint) char  asciiCl)) 

int  atoi( char  *s  )  > 

char  «bcd_asc( char  bed ) ) 

int  bcd_int(char  bed)) 

char  itctohlchar  byte)) 

char  int_bcdl int  decimal)) 

char  *itoal  int  n>  char  stJ)) 

char  tolowar)  int  c)) 

char  *uitoh( unsignad  int  word)) 


/a  This  routina  converts  a  tvio-byte  ASCII  string  representing  a  valid 
)^xadacimal  byte  into  a  single  tiexadacimal  byte.  •/ 

. . . 


char  atohCchar  oascii) 

/«  "ascii"  is  a  string  representing  a  hexadecimal  byte.  «/ 

{ 

int  i ) 

char  result)  /*  The  hexadecimal  byte  after  conversion.  •/ 


result  •  0) 

for  li>0)i  <  HSTRLEN  (I  ascii!  i]  !«  NUU)f«i)  < 
result  *=  16) 

if  (  'O'  <*  ascii[iJ  <t  '9'  >■  asciili)) 
result  asciili)  -  '0') 
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insignad  int  atohiaxintlchar  asciilll 
{ 

int  i  > 

unsigned  ini  result!  /*  The  hexadecimel  word  after  conversion.  «/ 
result  =  0) 

for  (i=0)i  <  HEXINTSTRLEN  it  asciitil  !=  NULLt+ti)  < 
result  *=  16 > 

if  (  'O'  <=  asciitil  iS  '9'  >=  asciitil) 
result  asciitil  -  '0') 
else  if  ('a'  <=  asciitil  tt  'f‘  >=  asciitil) 
result  +=  10  ♦  asciitil  -  'a*! 

) 

return) result )  ( 

) 

int  atoitchar  »s  )  convert  string  to  integer  »/ 

C 

static  int  n>  sign! 
sign  -  l! 
n  =  0) 

switch  ( *s )  < 

case  :  sign  =  -l! 

case  :  'f+s! 

) 

while  («s  >=  'O'  it  »s  <=  '9' )  n  =  10  »  n  ♦  *s+*  -  'O' ! 
return) sign  »  n ) ! 

> 


/*  Convert  a  byte  of  binary  coded  decimal  data  to  character  string  format.  »/ 
/a  No  cftecK  is  made  to  ensure  tftat  input  data  really  IS  in  BCD  format.  •/ 
char  abcd.asc) char  bed)  /»  Tested  March  16r  1987  a/ 

< 

static  char  asciitil! 
int  bedint! 

bedint  *  OxOOff  I  ))int)  bod)!  /a  Convert  to  integer,  a/ 

/a  If  the  tens  digit  is  a  zero>  put  a  blank  in  its  place! 

otherwise^  put  an  ASCII  digit  there,  a/ 
asciitOl  *  )0xf0  t  bedint)  ? 

)0x30  I  ) bedint  »  4))  :  '  '! 

asciitil  *  0x30  |  ))bcdint  X  OxOf))!  /a  Get  the  tnits  digit.  •/ 
asciitZl  3  NULL!  /a  Terminate  the  string  with 

a  null,  a/ 
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r*'tum(  ascii  )  > 


} 


/•  Convert  a  byte  of  binary  coded  decimal  data  to  integer  format.  */ 
/*  No  check  is  made  to  ensure  input  data  really  IS  in  BCD  format.  */ 
int  bcd_int(char  bed)  /*  Tasted  Harch  16 >  1987.  */ 

/*  "bed"  is  the  BCD  character  to  be  converted.  */ 

int  bedintf  result) 

/*  Take  the  units  by  masking  off  the  tens.  »/ 

/»  Then  throw  away  the  uiits  and  keep 
the  tens.*/ 

bedint  =  OxOOff  t  (int)  bed) 
result  ~  OxOOOf  6  bedint) 

/»Multiply  the  tens  by  10>  and  add  to  result.*/ 
result  ♦=  10  *  (bedint  »  4)) 
return( result ) ) 

} 


/*  Convert  a  character  to  hexadecimal  ASCII  string  format.  »/ 
char  *ctoh( char  byte ) 

static  char  asciil HSTRLEN ] ) 
int  byteint>  nibble*  base) 


bytaint  *  OxOOff  t  ((int)  byte))  /*  Convert  to  integer.  »/ 
nibble  =  byteint  >>  4)  /*  Get  the  tens  digit.  »/ 

/*  Find  out  whether  the  nibble  is  in  the  range  [0-9),  in  which 
case  its  ASCII  representation  starts  at  0x30  (48  decimal),  or 
t 10-151,  in  which  case  the  ASCII  representation  starts  at 
A  s  0x41  (65  decimal).  In  the  latter  case,  add  the  value  of  the 
nibble  to  65-10  =55.  •/ 
base  =  (nibble  >=  10)  ?  55  :  48) 
asciitO)  =  base  *  nibble) 

nibble  =  byteint  S  OxOf)  /•  Get  the  units  digit.  »/ 

base  =  (nibble  >=  101  ?  55  :  48) 
asciidl  =  base  *  nibble) 

asciiiZ)  =  NULL)  /*  Terminate  the  string  with 

a  null.  »/ 

return) ascii ) ) 


. . . . . . . 

/«  This  routine  converts  an  integer  to  a  binary  coded  decimal  character. 
Since  99  is  thie  largest  legitimate  BCD  number,  the  argunent  "decimal" 
is  taken  modulo  100.  •/ 
char  int_bcd( int  decimal) 

/»  "decimal"  is  the  number  to  be  converted.  «/ 

< 

int  result) 


/«  Hake  sure  decimal  is  a  i>ositiva  nuhber.  «/ 

decimal  =  (decimal  <  0)  ?  -decimal  :  decimal) 

decimal  X=  100)  /*  If  decimal  is  too  big,  take 
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it  modulo  100.  «/ 

rasult  =  (decimal  /  10)  <<  4>  /*  Get  the  tens  and  shift  them  into  the 

high  order  half  of  the  byte.  */ 
result  +=  decimal  '/.  10>  /a  Add  in  the  units.  */ 

retum((char)  result  )> 

} 

/a  itoa  -  convert  n  to  characters  in  s. 

This  program  is  from  TOOLNORKS  C/80t  Version  3.1>  by  Ifalt  Bilofsky.  a/ 
char  aitoalint  n>  char  s( 1 ) 

I 

static  int  Ci  Ki 
static  char  ap,  aqi 

if  ((k  =  n)  <  0) 
k  =  -kj 
q  =  P  =  sj 
do  < 

apt*  =  k  Z  10  ♦  'O' j 
}  while  (k  /=  10)1 
if  (n  <  0 )  *p++  =  j 

ap  =  0> 

while  (q  <  --p)  < 

c  =  »q)  aq++  =  ap)  »p  =  c)  } 
return  ( s  )  j 

1 

/a  tolower  -  if  the  input  is  in  [A..Z1»  convert  to  lower  case 
This  program  is  from  T(X)L(f0RkS  C/80>  Version  5.1»  by  Halt  Bilofsky.  a/ 
char  tolower) int  c) 

{ 

if  ( 'A'  <=  c  *S  c  <=  '2' ) 
return  (c  ♦  0x20)) 
return  c» 

} 

/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/ 
/a  Convert  an  unsigned  integer  to  hexadecimal  ASCII  string  format,  a/ 
char  auitoh) tnsigned  int  word) 

{ 

static  char  ascii (HEXINTSTRLEN  *  lit 
unsigned  int  nibble) 
int  i) 

ascii (HEXINTSTRLENl  >  NULL) 
for  Ci*0)i  <  HEXINTSTRLEN)**i)  < 

/a  Get  the  current  nibbla>  in  order  from  most  to  least  significant,  a/ 
nibble  >  OxOOOf  S  (word  >>  14  a  13  -  i)))) 

/a  If  nibble  >*  I0|  convert  it  to  a  letter  from  'A'  to  'F'. 

If  nibble  <  10>  convert  it  to  a  letter  from  *0'  to  '9'.  a/ 
ascii[i]  -  (nibble  >=  10)  ?  ('A'  *  nibble  -  10)  :  ('O'  *  nibble)) 

) 

return) ascii )) 

) 


M.  FILENAME  DELAY.H 


/«  This  fils  confsins  •x'tamal  prototyping  daclarations  for  all  functions 
in  "dalay.s".  •/ 

axtam  void  dslay(  int  n)> 


N.  FILENAME  DELAY.S 

>  dalay.s 

t  Adapted  from  a  program  by  Hr.  David  Rigmaidan  of  tha 
i  Space  Systems  Academic  Group  at  the  Naval  Postgraduate  School. 

ttdefina  LOOPCOUNT  1041 

>  Delay  for  n  hundredths  of  a  second. 

>  void  delay!  n) 

>  int  ni  /M  The  number  of  hundredths  of  seconds  of  delay  desired.  */ 

export  delay 
region  code 


delay; 

push 

ix 

t  tslST. 

!  Cause  ix  to  point 

to  the  first  parameter. 

Id 

ix>4 

1  t=14T. 

add 

ix,sp 

»  t=15T. 

Id 

c»(  ix+0 ) 

»  t=19T. 

Id 

b,(  ix*l ) 

j  t=19T. 

LOOPl: 

Id 

do,  $  LOOPCOUNT 

»  t=10T. 

L00P2: 

dec 

do 

>  t=  6T.  Count  down 

to  zero  in  LOOP2. 

Id 

a,d 

t  t=  4T. 

or 

o 

II 

H 

3P 

nz,L00P2 

1  t=10T.  Inner  loop 

t=Z4T. 

dec 

be 

t  ts  6T.  Repeat  LOOPl  until  time  is  up. 

Id 

9fb 

t  t=  4T. 

or 

e 

It 

H 

jp 

nz, LOOPl 

(  t=10T.  Outer  loop 

t=«54*24»LOOPCOUNT  )T. 

pop 

ix 

)  tsl4T.  Restore  ix 

to  its  initial  valua. 

ret 

>  t=10T. 

t  Total  Delay  ■(  106^l  54*24»LOOPCOUNT  )«n  )T. 

Solve  n»10  ms  «  (106+( 34+24*L00PC0UNT )«n)T  with  T  »  1/f  »  400  ns  to 
gat  n  >  LOOPCOUKT.  f  «  2.5  MHz.  For  n«100,  LOOPCOUNT  ■  1041 >  leading 
to  a  delay  of  1.0008  s  for  an  error  of  0.08/C.  For  n=li 
this  leads  to  a  delay  of  10.05  ms  instead  of  tha  100  ms  raquiredi  for 
and  error  of  0.5/C. 
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O.  FILENAME  EXPMNT.H 


oxtam  char 
ex-tarn  in-t 
ax-tam  void 
extern  char 
extern  char 
extern  char 
extern  char 
extern  void 
extern  void 
extern  void 
extern  void 
extern  void 
extern  char 
extern  char 
extern  void 
extern  void 
extern  void 
extern  void 
extern  char 
extern  char 
extern  char 
extern  char 


ad_read(char )) 

adtointtchar  addata>unsigned  long  multiplier)) 

alter_pageO( struct  pageOdata  «  pagezero)) 

bad_ idea. to_record( char  show)) 

baro_ switch) void ) t 

checKprt) void)) 

colder. than)  int  re-farence ) ) 

display.datajiaga)  struct  full_logj>aga  •  datapage ) ) 

display.pageO) struct  pageOdata  e  pagezero)) 

do.sweep) void ) ) 

expmnt) void ) ) 

initialize) void ) ) 

listen)  void)) 

logevent)char  event)) 

log.menu) void ) ) 

read.ad) void ) ) 

shut.down) void ) ) 

shut.down.no.log) void ) ) 

ssdrmode) char  mode)) 

ssdr.status) void ) ) 

voltages.low) void ) ) 

we.launched) void ) ) 


P.  FILENAME  EXPMNT.C 

/*  expmnt. c 

^include  "vibro.h" 
itinclude  "clocK.h" 

^include  "convert. h" 
ffincluda  "inout.h" 
it  include  "main.h" 

^include  "power. h" 

((include  "newio.h" 

((include  "bubble. h" 

((include  "global. h" 

char  ad_read(char  port)) 

int  adtoint(char  addata >unsigned  long  multiplier)) 

void  alter.pageO( struct  pageOdata  •  pagezero)) 

char  bad_idea_to_record)char  show)) 

char  baro_switch)void)) 

char  checKprt) void )) 

char  colder. than) int  reference)) 

void  display_data.page) struct  full.log.page  •  datapage)) 

void  display.pageO) struct  pegeOdata  •  pagezero)) 

void  do.sweep) void)) 

void  expmnt) void ) ) 

char  initialize) void)) 

char  listen) void)) 

char  logevent) char  event)) 

void  log.menu( void ) ) 

void  monitor_heaters)void)) 


void  post_l«unch(void)t 
void  r«cord( void ) ( 
void  shut_down( void)) 
void  shut_down_no_loglvoid)i 
char  ssdniioda(  char  moda)) 
char  ssdr.staiuslvoidlt 
void  shor't_axpariiiian't(void)t 
void  show.avantfchar  event  )t 
char  voltages_loM( voidit 
char  we_launched(void'M 


1/ 

This  routine  gets  data  from  the  analog  to  digital  converter.  •/ 
char  acLreadlehar  port) 

< 


output)  port  >0  )t  /«  You  must  write  to  the  port  before  you 

can  read  it.  */ 

delay! 1  )t 

return! input! port ) )  > 


) 


/»  This  routine  converts  a  byte  of  data  from  the  A/D  converter  into  an 

integer.  In  order  to  reduce  the  amount  of  code  generated  by  the  compiler* 
it  uses  no  floating  point  operations. 

The  routine  assumes  that  the  converted  value  lies  on  a  line  which  passes 
through  the  origin  and  whose  slope  I  in  some  arbitrary  units)  is  given  by 
the  multiplier.  Consequently*  this  routine  always  converts  value  of  zer 
to  zero. 

To  obtain  the  correct  multiplier  amounts  to  calculating  the  slope  and 
scaling  it  to  permit  integer  operations  to  succeed. 

For  example*  assume  that  a  value  of  255  in  the  A/D  converter  ! the 
maxiiman  possible)  represents  15V.  A  difference  of  1  in  tfie  value 
read  by  the  A/D  converter  represents 

ISV  /  255  divisions  =  58.8235  mV/division, 
fhjltiply  this  by  1E6  and  round  off  to  get  the  basic  multiplier; 

58.8235  «  1E6  =  58824. 

Using  this  multiplier  will  give  results  in  units  of  volts.  To  get  units 
of  tenths  of  volts*  say*  increase  the  multiplier  by  a  factor  of  10  to 
588*240.  The  result  will  be  an  integer  representing  the  chosen  units) 
the  decimal  point  is  implied  to  be  to  the  left  of  the  rightmost  digit. 

To  avoid  an  overflow  upon  multiplication*  the  multiplier  should 
be  Kept  less  than 

!2»«32)/25S  s  16*843*009. 

The  greates  achievable  accuracy  is  obtained  tdien  the  siultiplier  is  scaled 
tp  by  multiplies  of  10  as  much  as  possible  without  exceeding  this  limit. 

»/ 

int  adtoint!char  addata*trisigned  long  multiplier) 

< 

/4  During  conpilation*  this  line  will  be  flagged  because  it  presents 
the  possibility  of  truncation.  The  problem  is  not  serious  as 
long  as  the  limit  on  tfM  multiplier  is  observed*  as  discussed  above.  •/ 
unsigned  long  value)  /»  A  long  integer  version  of  "addata".  •/ 

value  >  ! unsigned  long)  addata) 
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ratumi ( int )  (((valua  *  multipliar )  *  500000L)  /  lOOOOOOL))) 

> 


/»  This  routina  allows  tha  usar  to  altar  tha  flags  and  pointars  in  paga  zaro 
for  tha  purposa  of  parmitting  program  functions  to  ba  tasted  thoroughly. 
Use  caution  in  altering  them.  »/ 


void  altar_pageO( struct  pagaOdata  a  pagazero I 


char  data> 

char  changes  -  FALSE ) 


/»  Holds  a  character  from  tha  keyboard.  */ 

/a  TRUE  if  tha  paga  zaro  needs  to  ba  altarad> 
FALSE  otherwise.  Ha  know  that  no  unsaved 
changes  have  bean  made  to  page  0  before  this 
routine  is  invoked*  so  wa  set  this  to  FALSE 
initially.  */ 

/a  Variable  "flag"  is  usad  to  permit  tha  values  0  and  1  to  ba  displayed 
as  FALSE  and  TRUE  respectively.  */ 
static  char  aflagi ]  =  < 

"FALSE"* 

"TRUE" 

}J 


/a  Display  this  menu  repetitively  until  choice  Z  is  made,  a/ 
while(TRUE)  i 
printf( " 

A  Toggle  '  sweeps  tar  ted'  flag  from  '/s  to  Zs.  nr 

B  Toggle  'launchdona'  flag  from  Zs  to  Zs.  nr 

C  Alter  value  of  next  available  paga  from  OxZx  -  Zd.  n  r 

0  Alter  value  of  next  available  half  page  from  Zu  to  Zu.  nr 

E  Toggle  ' full_exper iment *  flag  from  Zs  to  Zs.  n  r 

F  Specify  the  'RECORO_start_time'  (make  this  at  least  12  hours  before  the  n  r 
present  to  permit  RECORD  mode  to  be  initiated. ) n  r. 

Z  Exit  this  menu.  nr"> 

f lag(pagezero->sweepstarted  ?  1  :  0  I* 
f lagCpagezero->sweepstarted  ?  0  ;  1  1* 
f lag(pagezero->launchdone  ?  1  :  0  1* 
f lagCpagezero->launchdone  ?  0  :  1  1* 
pagazero- >page *  pagezero->page* 
pagezero- >ha 1 f page  > 

(pagezero->halfpaga  ==  0)  ?  1  ;  0* 
flag[pagezero->full_axpor iment  ?  1  :  0]> 
flag[pagezaro->full_exper iment  ?  0  :  11 

)» 

/a  Input  a  character*  convert  it  to  lower  case*  and  display  it.  a/ 
data  *  tolower( termini ) )) 
pr intf  I  "Zc  n  r" *data ) i 
switch  (data)  C 

case  'a':  /a  Complement  tha  "sweepstarted"  flag,  a/ 

pagezero->sweepstarted  *  !pagezero->sweepstarted) 
changes  >  TRUE l 

break>  /a  Complement  the  "launchdona  flag,  a/ 
case  'b': 

pagezero->launchdone  *  !pagezero->launchdone) 
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changas  =  TRUE» 
braaK  t 

casa  'c':  /*  Ask  tha  usar  for  a  paga  nunbar.  Lat  this  ba  tha 

naxt  paga  used  for  racording  i tains  in  tha  log.  */ 
pagozoro->pago  =  gatpagcno( 
changas  =  TRUE! 
braaK i 

case  'd':  Complamant  tha  "halfpaga"  nunbar.  */ 

page2aro->halfpaga  =  lpaga2ero->halfpaga  ==0)71  :  0) 
changes  -  TRUE) 
break  > 

case  'a':  /«  Conplamant  tha  "full.axparinant"  flag.  •/ 

pagazero->full_axpariment  »  !paga2aro->full_axparinientt 
changas  TRUE) 
break l 

case  'f:  /»  Ask  tha  usar  for  a  new  ''RECORD_start_tima".  «/ 

get_tinia(A  ( pagezaro->RECORO_start_tinia )  )> 
changes  =  TRUE | 
break) 

case  'z':  /a  If  any  changes  have  been  nade>  store  them  in  paga 

0  and  quit  this  routine.  */ 
if  (changes)  < 

if  ( !bubio( BMRITE >0>( char  »)  page0_buf far ) )  C 
printf(  "Update  to  page  0  failed,  nr")) 

) 

1 

return) 

default: 

printfC'Usa  a  valid  letter*  please,  nr")) 

) 

) 

} 

This  routine  checks  to  see  whan  RECORD  mode  was  last  initiated. 

If  this  time  was  within  tha  last  IZ  hours*  tha  routine  returns  TRUE* 
meaning  that  it  is  not  a  good  idea  to  enter  RECORD  mode  now.  This 
will  avoid  a  situation  where  RECORD  mode  is  restarted  in  the  middle 
of  a  mission*  wiping  out  tha  recorded  data,  "show"  must  ba  TRUE  to  display 
tha  time  when  RECORD  mode  can  begin.  If  it  is  FALSE*  the  display  is 
suppressed,  k/ 

char  bad_idaa_to_record(char  shawl 

struct  datatima  current_tiisa) 

struct  idatatima  icurrant.tima)  /«  Integer  version  of 

currant  time.  */ 

struct  idatatima  istorad_tima)  /«  Integer  version  of 

stored  time.  •/ 

struct  idatatima  iRECORO_dalay_tima)  /»  Integer  format  of  time  whan 

RECORD  mode  can  begin.  •/ 

struct  idatatima  iREC0R0_dalay_oonstant)  /*  Integer  format  of  minimum 

time  batwaan  successive 
startings  of  RECORD  mode.  •/ 

iREC0RD_dalay .constant. imonth  ■  iRECORD_dalay_constant. idata  * 

iRECORD_dalay_constant. iminuta  =  iRECORO.dalay.constant. i second  >  0) 
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iRECORD_d«l«y_const«nt.ihour  s  RECORO.OELAYi 

/»  Gat  tha  currant  data  and  tima  and  convart  to  intagar  format.  »/ 

clockraadl tcurrant_tima )  > 

clocKint(  tcurront_tiniatSicurrant_tima  li 


/*  Gat  tha  data  and  tima  storad  in  tha  bubbla  mamory  as  tha  last  tima 
that  RECORD  moda  was  initiatad  and  convart  to  intagar  format,  a/ 
clock int ( t( pagazoro->RECORO_s tar t_t ima ) >  >istorad_t ima ) > 

/*  Add  tha  two  datas  and  timas  to  gat  tha  naxt  tima  whan  RECORD  moda  can 
ba  initiatad.  a/ 

clocksumf (iRECORD_dalay_timaiAistorad_tima>AiRECORD_dalay_constant )t 
if  (show)  { 

printfC "Currant  tima:  ")> 
dutnp_clocK(  tcurrant.tima )  i 

printfC'Tima  whan  RECORD  moda  last  was  bagun:  ")> 
dump_clock( A( pagezaro->RECORD_start_tima  1 1 1 
printf("Tima  whan  RECORD  moda  can  ba  bagun  again:  '')i 
dump_iclock( tiRECORD_dalay_tima )  l 

) 

/a  Raturn  TRUE  if  tha  currant  data  and  tima  is  lass  than  RECORD.DELAY 
hours  after  tha  storad  data  and  tima.  Otharwisa>  return  FALSE,  a/ 
return) clockcompara) tiRECORD_dalay_tima>kicurrant_tima ) )> 


/a  Check  to  saa  if  the  barometric  pressure  switch  tripped. 

Make  an  entry  in  tha  log  and  return  TRUE  if  so>  return  FALSE  otherwise,  a/ 
/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/ 
char  baro_switch( void) 

< 


char  addata> 


/a  Holds  a  character  from  port  READCl.  */ 


/a  If  the  BARO_ON  bit  of  tha  READCl  port  is  TRUE»  than  the  barometric 
switch  has  bean  trigsiarad.  */ 
addata  =  input) READCl ) i 
if  (addata  (  BARO.ON)  < 

printf) "Barometric  switch  triggered,  n.r”  )) 
logavant) OPRESSURE ) > 

1 

) 


. . . . . 

/a  This  routine  checks  to  saa  if  there  is  a  printer  comacted  to  tha 
controller.  It  returns  TRUE  if  tliara  is  ona>  FALSE  otherwise,  a/ 
char  chaekprt(void) 

< 

/a  If  tha  TERMON  bit  of  tha  READCl  port  is  0,  than  a  tarminal 
is  connactad.  In  this  casa  ratum  TRUE>  FALSE  otharwisa.  a/ 

raturn)  (  iryiut)  READCl ) )  t  TERMON )» 

) 
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/*  Thi«  function  displays  tha  data  in  paga  zaro.  «/ 
void  display_pagaO( struct  pagaOdata  •  pagazaro) 

printfCSwaapstartad  >  '■)» 
if  ( pagazaro- >swaapstartad) 
printfC'TRUE  ")j 

alsa 

printfl  "PAUSE  ")» 
printf I  "Lacnchdona  > 
if  (pagazaro->lavzichdona'i 
printfr’TRUE  "li 

alsa 

printfJ "FALSE  ")i 
printf I "Full-axpmnt  «  ")| 
if  lpagazaro->full_axparimant) 
printfC’TRUE  n  r"  )j 

alsa 

printf (  "FALSE  n  r" )j 

printf) "Last  tima  RECORD  moda  was  initiatad:  ")» 
dunp_clocK(  t(pagazaro->RECORO_start_tiffla)  It 


} 


printf  ("  n  rNaxt  paga  =  Ox'/.x  -  ‘/.u  ">  pagazaro->paga>pagazaro->paga  )  i 
printf)  "Naxt  halfpaga  ~  Ox'/.x  =  /!unr">  pagazaro- >halfpaga> 

pagazaro->halfpaga ) t 


/*  This  function  ratums  TRUE  if  tha  bubbla  matnory's  tanparatura  is  balow 
tha  rafaranea  valuat  FALSE  otharwisa.  */ 
char  eoldar_than) int  rafaranea  I 

char  addatai  Helds  a  character  from  tha  A/D.  »/ 

int  tamparaturai  /«  The  currant  temparatura  in  degrees  K.  */ 

/»  Read  in  tha  temparatura  of  tha  bubbla  memory.  •/ 
addata  =  ad_read)  TEI1P4  )  | 
temparatura  =  adtoint) addata >MULT_TEMP  It 
return) ) temparatura  <  rafaranea  I  ?  TRUE  :  FALSE  1 1 
J 


/) 


>/ 


/*  This  fuietion  displays  a  paga  of  data.  «/ 
void  display_data_paga) struct  full_logLpa9a  adatapagal 
< 


char  addatai 
int  paga I 
int  halfpagat 
int  it 
int  valuat 


/•  Holds  a  character  of  data  from  tha  A/D.  a/ 
/«  Tha  desired  paga  number,  a/ 

/*  Tha  currant  halfpaga  number. a/ 

/a  Counts  through  tha  valid  A/D  addrosses.  a/ 
/a  Tha  data  from  tha  A/D  convartad  into  useful 


units,  a/ 


printf)  "Fttich  page  of  data  do  you  want  to  saa?nr")t 

paga  ■  gatpagano) It 

if  ) !bubio)BREAD>paga>log_buffar 1 1  < 

printf)  "Couldn't  read  paga  Xu.  nr'Spagali 
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ratumj 


> 

prirctf  I  “Con'tsnts  of  pag«  OxXx  -  V.6-.  n  r" >pag* >pag«  U 
for  (halfpage=Oihalfpag«  <  BL0CKS_PER_PA6E t^+halfpaga )  { 
printfC'Half  paga  Xd:  n  r  t"  fhalfpaga )  t 
dunp_clocK(  <(da'tapaga->half_paga[halfpagal. clock)  )( 
shoM_av8nt(  da'tapaga->half_paga(halfpagel.avant  )> 

/*  "adcapfion"  is  dafirwd  in  fila  “global. c".  */ 
for  (i=0»i  <  ADPOim'St'f+i )  { 

addata  -  dafapaga->half_pagothalfpagal.atodl i  )( 
prinifi  “X-24s=X3.0d=“>adcapf iont i )>addata  )( 

if  li  <=  Z)  {  /*  Tha  A/O  raading  is  a  volfaga«  in  this  casa.  »/ 

valua  =  adtointC addata, ( i==Z)?MULT_10V  :  MULT_20V)i 
printfC'XcXZ.Od.XOZ.OdV  “,(  i==l)?‘-’ :  , 

valua/100  tvaltiaXlOO )  ( 

}  '.sa  {  /*  TtM  A/0  raading  is  a  taraparatura,  in  this  casa.  »/ 
valua  =  adtointi addata, MULT_TEMP ) ( 
pr intf I "X6 . OdK  ", valua  )> 

) 

/»  Print  two  points  par  lina.  »/ 
if  (  (0  !=  i  X  2)  I (  i  ==  ADPOINTS  -  1) 
printf ( "  n  r"  )  > 

J 

) 

1 

/*  This  function  causes  tha  “sweap"  to  ba  parformed.  */ 
void  do_swaep( void  I 
< 

printf)  "Turn  on  SSOR  and  A/0  Coovartar  and  place  SSOR  in  SIHEEP  node,  n  r"  )  i 
logevent(powar_write(ADON)  ?  CSONAO  :  CFONAO)> 
logevent(power_write(SSORON)  ?  CSONSSDR  :  CFONSSOR  ) » 
logevent) ssdrmode(SNEEP  I  ?  CSSWEEP  ;  CFSHEEP)> 
printf (  "IHait  10  seconds  before  starting  sweep.  nr'')> 
timeout)  10,SECON0S)t 

/•  Wait  for  timeout  or  for  a  key  to  ba  pressed.  */ 
while)  ! timeout) NULL >N)JLL)  I  < 
if  ) look_ahcad_discard)  ) ) 
break ( 

J 

printf)  "Turn  on  VCO.  Wait  15  minutes.  nr")> 
logevent)  powar_writa(VC0(3N)  ?  CSONVCO  ;  CFONVCO)) 
timeout) 13, MINUTES  It 
while  )TRUE)  < 

if  )ssdr_status) )  ss  OPCOMP)  < 
logevant )  OOPOJMP  )  t 
break! 

) 

if  ) timeout) NULL, NULL  )  ||  look_ahaad_discard)  ) )  { 
logevant) ONOOPCOMP I  > 
break i 

) 

) 

printf )  "Sweep  phase  is  over.  Turn  off  VCO,  A/D  Converter,  and  SSOR.  nr"  It 
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log*vant(poM«r_writ«(VCOOFF)  ?  CSOFFVCO  :  CFOFFVCOIt 
losavant(power_Mrit«(SSDROFF)  ?  CSOFFSSOR  :  CFOFFSSDRli 
logav«ntlpow«r_writ«(ADOFF)  ?  CSOFFAO  :  CFOFFADU 
losavant( DSHEEP ) » 

} 

. . . 

/»  This  function  performs  the  Vibro-aeoustic  experiment.  «/ 
void  expnnt(void) 

{ 

char  mission_status>  /»  Can  be  OAPUON.  OLAUNCH*  DOPCQMP,  DNOOPCOHP, 

or  OABORT.  Used  to  control  program  flow.  */ 


if  ( ! initialixal ) I  < 

printf ( "The  bubble  memory  log  is  full.  \ 

Riming  the  experiment  anyway.  nr")t 
) 

/*  Check  to  see  whether  we  should  operate  the  full  experiment  or  not.  »/ 
if  ( !pagexero'>full_experiment )  < 
short_experiment(  )t 
return » 

} 

/*  Check  the  sweepstarted  flag  in  page  zero  of  the  controller's  bubble 
memory.  It's  TRUE  if  the  sweep  has  been  started  previously* 
false  otherwise.  »/ 
if  ( * ( pagezero->sweepstarted ) )  < 

printf (  "Starting  the  sweep.  nr")> 
do_ sweep! ) t 
}  else  < 

printf ( "Sweep  was  done  previously*  so  we're  skipping  it.  nr")> 

) 

/•  Check  the  launchdone  flag  in  page  zero  of  the  controller's  bubble 
memory.  It's  TRUE  if  the  lainch  has  already  taken  place)  FALSE 
otherwise.  *•/ 

if  (!( pagezero-> launchdone I )  I 

/•  Keep  on  listening,  until  you  detect  either  the  APU,  or  the 
launch.  If  you  run  out  of  time*  assume  the  mission 
was  aborted,  a/ 

printf  I  "He  haven't  lainched  yet.  Listening  for  the  APU.  nr")) 
mission.status  ■  listen!  )) 

printf I "Turning  on  the  SSOR*  because  listen!  )  detected  something.  n,r")) 
logevent(power_write(AOON)  ?  CSONAO  :  CFONAOM 
logevent!pawer_write!SSORQN)  ?  CSONSSDR  :  CFONSSDR)) 
if  !missian_status  ««  OAPUON)  < 

printf!  "APU  is  on.  Initiate  a  10  minute  timeout.  n  r\ 

Placing  SSDR  in  SCROLL  mode.  nr"li 

logavantlssdrmode!  SCROLL  I  ?  CSSCROLL  :  CFSCROLDl 
timeout! 10 *MINUTES)» 
while  I  TRUE)  { 

if  ! we.launched! )  ■«  DLAUNCH)  I 
printf! "He  launched,  n  r"  )| 
mission.status  ■  OLAUNCHi 
break  > 
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) 

if  ( tiiMoutC  MJLL  >hULL )  ||  look_»h«ad_discard(  ) )  { 

printf  (  "Ma  timed  out  and  are  aborting  the  mission.  nr")( 
mission_status  =  DABORT i 
logeventf  DABORT )  | 
break i 

) 

) 

> 

}  else  {  /*  Launch  was  done  previously,  s/ 
logevant( PRIORLAUNCH ) » 
mission.status  >  PRIORLAUNCH t 

printfC'He  have  previously  launched  and  are  in  space  now.  nr 
Assume  mission  has  been  successfully  completed.  ,n  r"  U 
) 

if  I mission_status  -=  DLAUNCH)  i 

printf  ("Putting  the  SSDR  in  LAUNCH  mode,  nr 
Initiating  a  3  minute  timeout.  nr")t 

logevent(ssdrmode( LAUNCH  I  ?  CSLAUNCH  ;  CFLAUNCH)» 
timeout( 3, MINUTES )» 
while  (TRUE  )  < 

/«  If  we  haven't  recorded  a  conqiletad  launch>  check  the  barometric 
switch.  If  it  has  been  triggered^  then  we  should  record  one.  */ 
if  (  !pagezero->launchdone ) 
baro_switch( 

if  ( ssdr_status(  )  ==  DOPCOMP )  £ 

printf ("SSDR  reported  OP  COMPLETE,  n  r"  )  > 
logevent( DOPCOMP  )  > 
break i 

) 

if  ( timeout  (NULL  iNiyCL  (  ((  laok_ahead_diseardl  ) )  £ 

printfC'SSDR  never  reported  OP  COMPLETE.  We  timed  out.  nr")> 
logevent( DNOOPCOMP I t 
break  k 

) 

) 

} 

if  ( mission_status  DABORT) 
post_ launch  (  )» 

} 


/»  This  routine  reads  page  0  from  bubble  memory  in  order  to  initiate  the 
e>q3eriment  properly.  »/ 
char  ini tialize( void) 


£ 


Int  it  /*  A  counter  which  permits  more  than  one  attempt 

to  read  the  bubble  memory.  */ 

char  paHer_port»  /•  Holds  the  status  of  the  power  subsystem.  */ 


printf ("Read  from  page  0  of  the  bubble  memory,  nr") t 
/«  Attempt  to  read  from  page  0  up  to  BTRIES  times  before  giving  up.  */ 
for( isOt!bubio( BREAD iOipagaO_buf far )  It  i  <■  BTRIES)««i)t 
display_pageO( pagazero ) » 
if  ( pagezaro->paga  >  MAXPAGE  )  £ 
return) FALSE )) 
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) 

fop(isO»i  <  BTRIES>  +  +  i)  t 

if I bubiol BREAO>pag«zaro->pag«>log_buff«r  )  I  { 
printf  (  "iogeven'K  INITIALIZE  )  n  r" 
logavant( INITIALIZE ) i 
powar_port=powap_statu*( )t 
if  (VCOOFF  t  powar_popt)  < 

prinffC  "Turning  fha  VCO  powar  subsystam  off.  np")» 
logevantc powar_writa( VCOOFF  )  ?  CSOFFVCO  :  CFOFFVCO)! 

) 

if  (HEATOFF  t  powar_port )  < 

Iogavanf(powap_wpifa(HEATOFF»  ?  CSOFFHEAT  :  CFOFFHEATJj 
printf  ( "Turning  tha  haatar  siAsystam  off..np"U 

} 

raturni TRUE ) t 

) 

} 

returnt  FALSE  I j 

) 


/«««««««*«»«»«««»«««»««»*«»*«•*«»«««»*«»«««»»»»«»»»«»»»«»«»»•»»»»»•»»»»»»•«»/ 

/*  This  ftrwtion  raturns  OAPUON  if  tha  APU  is  on>  DLAUNCH  if  tha  shuttle 
has  launched)  FALSE  if  neither  event  is  detected)  but  exit  is  forced  by 
the  pressing  of  any  key  on  tha  terminal.  */ 
char  listen) void) 

< 

char  portcl)  /*  This  holds  tha  contents  of  NSC&IO  #1  port  c.»/ 

printf  ( "Turning  Matched  Filter  on.  Halt  for  detection  or  a  Keystroke,  nr")) 
/*  Turn  on  the  matched  filter>  and  listen  for  the  APU.  If  the  matched 
filter  is  already  on»  this  command  has  no  effect.  */ 
logovent(power_write(MATFON)  ?  CSONMATF  :  CFONMATF)) 
while  (TRUE)  < 

if  lwo_launched(  )  ==  DLAUNCH) 
return)  DLAUNCH)) 

portcl  ~  input) RE ADCl ) t 
if  (portcl  t  APU.ON)  { 

printf)  "APU  detection  occurred.  nr">> 
logevant)  OAPUON)) 
return) OAPUON)) 

) 

/•  Exit  this  function  if  any  Kay  on  tha  tansinal  is  pressed.  •/ 
if  ( look_ahaad_discard( )) 
return) OUSERNOAPU ) ) 

} 

J 


/*  Log  an  event.  This  function  returns  TRUE  if  tha  event  was  logged 
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satisfactorily*  FALSE  otharwise.  a/ 
char  logavantichar  avant) 

< 

int  ij  /»  A  cobntar.  »/ 

char  »buffar_ptrj  /»  A  pointar  into  tha  log  paga  buffar.  a/ 

char  full)  /a  TRUE  whan  all  availabla  pagas  ara 

usad  a/ 

buffar_ptr  *  log_buffar)  /a  Maka  buf far_ptr  point  to  tha  start  of 

tha  log  buffar.  a/ 

full  a  pagazaro->paga  >  MAXPAGEt 


/a  If  tha  bubbla  manory  is  full*  thara's  no  point  in  going  on.  Ratum.  a/ 
if  (full) 

ratumt  FALSE )  i 

/a  Blank  out  tha  buffar  if  this  is  a  naw  paga.  This  guarantaas  that 
old  data  won't  rasida  in  tha  tppar  half-paga  whan  tha  naw  paga  is 
written  to  the  bubble  memory,  a/ 
if  (pagezero->halfpaga  ==  0 )  < 

for  (i=0ji  <  PAGELEN6TH(>  +  i )  { 

( abuf far_ptr*+ )  *  0x00) 

} 

/a  Fill  tha  currant  log  block  with  new  data  to  be  logged,  a/ 
clock read ( 

S( 

log_page-> 

half_paga(pagazaro- >ha 1 f page  I . c lock 

) 

)) 

le»g_paga-> 

half_paga(pagezero*>halfpaga].evant  s  event) 


/a  Read  tha  A/Ds  and  put  their  contents  in  tha  log*  too.  a/ 
for  (i=0)i  <  ADPOINTS)i++)  < 
lo9_pago-> 

half_pagelpagazero->halfpagal.atodl i 1 
s  ad_raad(adport( i ] )) 


) 


if  (avant  »  CSSWEEP  ||  avant  »  CFSHEEP)  < 
pagazaro->swaapstartad  ■  TRUE) 

} 

if  (avant  »  OPRESSURE)  < 

pagazaro->la)«)chdona  ■  TRUE) 

} 

/a  Hrita  the  naw  page  of  data  to  tha  bubbla  mamory.  a/ 
bubio( BHRITE  »pagazare->paga > log_buf  far ) ) 
if  (pagazaro->halfpaga  >*  BLOCKS_PER_PAGE  -  1)  t 
if((t*(pagazaro>>pags))  >  MAXPAGE )  < 

printf(  "Bubbla  masiory  is  all  usad  I4>>\n,r")) 
ratum(  FALSE ) ) 

} 

pagazaro->halfpaga  ■  0) 

}  else  { 
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«'»( p«g«zaro->hal'fpaga )  > 


} 

/•  Upda'ta  paga  0  in  the  bubble  memory.  */ 
bubiol BWRITE  >0  >pageO_buf fer ) t 

return! TRUE  ) >  /*  If  you  got  thi«  far>  you  know  you  haven't  yet 

run  out  of  bubble  memory.  Return  TRUE  to  show 
successful  logging  of  an  event.  •/ 

} 


/*  This  routine  provides  a  menu  of  choices  for  examining  or  changing  the 
contents  of  the  bubble  memory.  */ 
void  log_menu(void) 

< 

char  datat  /a  Holds  a  character  from  the  Keyboard.  */ 

/*  Read  page  0  from  the  bubble  memory.  */ 
if  ( !bubiol BREAD >0 >pageO_buffer ) )  ( 

printf  (  "Couldn' t  read  page  0.  nr“)) 
returns 
J 

/*  Display  the  menu  repetitively  until  Z  is  chosen.  »/ 
while  I  TRUE  I  < 
printf!  " 

A  Display  page  0.  n  r 
B  Display  a  page  of  the  log.  n  r 
C  Alter  the  contents  of  page  0.  nr 
Z  Exit  this  menu,  nr" 

)t 

data  ^  tolower! termin!  Ill 
printf!  "'/.c  n  r"  >data  1 1 
switch  ! data  I  < 
case  'a ' : 

display_page0! pagezero  li 
break l 
case  'b ' ; 

display_data_page( log_page ) i 
break  I 
case  'c' : 

alter_page0( pagezero I i 
break I 
case  'z': 

return) 
default : 

printf! "Use  a  valid  letter  please. ' n\ r"  )i 

) 

} 

} 


/•  This  routine  monitors  the  temperature  of  the  bubble  memory  used  for 
logging  data  and  operates  the  heaters  to  keep  the  temperature  within 


th«  d««ir«d  rang*.  */ 
void  monitor_h«aters(void) 

{ 

char  poM«r_porti  /*  Holds  tha  status  of  tha  power  subsystem.  */ 
poMar_port  s  poNer_statusl  )t 

/a  If  it  is  cold  anou^>  and  if  tha  heater  is  not  yet  on>  turn  it  on.  */ 

if  ( colder. than( MIN_DESIRABLE_TEMP )  tt  (HEATOFF  A  power^port ) )  { 
printfC'Turn  on  the  heaters,  .n  r" )( 
logevent(power_writa( HEATON)  ?  CSONHEAT  :  CFONHEAT)» 
return > 

} 

/»  It  is  is  warm  anous^t  and  if  the  heater  is  already  on,  turn  it  off.  */ 

if  ( I !colder_than(HAX_OESIRABLE_TEMP))  AA  < HEATOFF  A  powerjjort )  )  { 
printf  (  "Turn  tha  heaters  off.  nr")t 

logaventtpower_write( HEATOFF)  ?  CSOFFHEAT  :  CFOFFHEAT  U 

} 

} 

void  PCS t_launch(  void ) 

t 

printf(  "We're  shutting  down  all  power.  nr")( 
shut_down( ) i 
while  (TRUE)  <. 

printf ( "Reading  A/Ds  every  5  minutes.  nr")> 
timeout(5,HINl/TESI» 
while  (! timeout) NULL, NULL))  C 
mon i tor.hea  ter s  (  ) ( 
if  ( !pagezero->launchdone ) 
baro_ switch)  )> 
if  ( looK_ahaad_discard(  ) ) 
breaK i 
J 

logevent) READAO ) > 
if  ) voltages.low) ))  < 

printf (  "Voltages  are  too  low.  Terminate  the  experiment.  nr")j 
logevent) TERMINATE ) ) 
breaK i 

} 

J 

} 


/a  This  routine  parfonss  the  RECORD  phase  of  the  abridged  experiment,  a/ 
void  record) void) 

{ 

printf ( "Entering  RECORD  node.  n'r\ 

Turning  on  SSDR  and  A/D  Converter,  n  r")i 

/a  Store  current  time  in  page  0.  This  is  a  record  of  tha  time  when 
RECORD  mode  last  was  bej^r).  Tha  next  time  logevent)  )  is  called, 
tha  data  will  actually  be  stored  in  page  0.  a/ 
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clocKraadl  tl  pag«zaro->RECORD_s'tar't_tiiM) )( 
logaventC power_writa( ADON )  ?  CSONAD  :  CFONADtt 
logevant(poMar_wri'talSSDRON)  ?  CSONSSOR  :  CFONSSDR)» 
logavanti ssdrmodal RECORD )  ?  CSRECORO  :  CFRECORD)» 
printfC "Initiating  a  ZO  minuta  tinaout.  n  r"  )| 
timaout( ZO, MINUTES )i 
Nhila  (TRUE)  < 

/*  If  wa  havan't  yat  lair)chad>  chack  to  saa  if  tha  baronatric 
switchas  hava  firad  or  not.  */ 
if  ( !pagozaro->launchdona  I  < 
baro_switcM( )( 

) 

if  ( ssdr_status(  )  »»  OPCOMP )  { 
logavanti OOPCOMP )  l 
braaki 

) 

if  I  timeout! NULL >NULL)  ||  look_ahaad_discard(  ) )  { 
logevant ( ONOOPCOMP ) ( 
break  V 

} 

) 

printfl  "Record  phase  is  over.  Turn  off  A/0  Cotwerter  and  SSDR.  nr")* 
logevant! powar_writa(SSOROFF I  ?  CSOFFSSOR  :  CFOFFSSDRl) 
logevent! powar_Mrite! ADOFF )  ?  CSOFFAO  :  CFOFFAD)) 


#«»«*•»«•»»«»«•«««««»»»/ 

/»  This  routine  operates  an  abbreviated  version  of  tha  experiment  which 
avoids  doing  tha  "sweep",  and  uses  only  RECORD  mode  in  tha  SSDR.  ^^/ 
void  short.experimenti void ) 

< 

char  showflag)  /*  This  flag  is  TRUE  to  make  bad_idea_to_ record!  ) 

display  computed  times)  FALSE  otherwise.  */ 
if  ! pagezero->launchdone  I  < 

printf!")4e  hava  previously  launched  and  are  in  space  now.  nr")) 
logevent!  PRIORLAUNCH ) ) 

) 

while!  !pagezerO'>laij^chdone )  < 

/a  If  RECORD  mode  was  initiated  too  recently,  wa  don't 

want  to  try  it  again.  Hait  for  a  suitable  interval  to  elapse  before 
continuing.  bad_idea_to_record(  )  knows  how  long  this  is. 
Alternatively,  the  user  can  press  a  key  to  avoid  waiting.  •/ 

showflag  ■  TRUE)  /•  Hava  bad_idea_to_recordl  )  display  computed 

times  the  first  time  throus^.  «/ 
t^ila  !bad_idea_to_record!  showflag)  J  { 
showflag  ■  FALSE) 
if  ! look_ahead_discard!  )) 
break) 

) 

/•  Nait  for  indications  of  a  launch.  »/ 
listen!  )) 

/»  Enter  RECORD  mode.  »/ 
record!  )) 
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if  ( !pag«z*ro->launchdon«) 
baro_ switch!  !j 

) 

/*  Now  that  we'ra  in  spaca>  parform  post-launch  operations.  */ 
post. launch! )( 

) 

/aauMMMiwaawmiiimiiiiiMMWiiaaiiimMmiimMmiaaaaMMMMaaaaawxMmisaMSMiiiiiiKimwwMwiiaaat 
/*  This  function  displays  tha  maaning  of  an  avant  coda.  «/ 
void  show_avant!chap  avant) 

{ 

/»  “avant"  is  an  index  into  tha  following  array  of  massages. 

It  is  one  of  tha  avant  codas  given  in  tha  “vibro.h"  file. 

If  someona  changes  it>  someone  had  batter  change  these  massages  to 
corraspondt  or  tha  results  will  be  disappointing.*/ 
static  char  »massagaC 1  =  < 

"Initialization,  n  r"> 

"Sweep-mode  command  issued.  nr"t 
"Sweep-mode  command  accepted.  n  r"> 

"Sweep-mode  command  not  accepted.  nr"> 

"Sweep-mode  completion  detected,  n  r"r 
"APU  detected.  nr"> 

"Scroll-mode  command  issued,  n  r"> 

"Scroll-mode  command  accepted,  nr", 

"Scroll-mode  command  not  accepted,  nr", 

"Launch  detected,  n  r", 

"Launch-mode  command  issued,  n  r", 

"Launch-mode  command  accepted n  r" , 

"Launch-mode  command  not  accepted,  nr", 

"Barometric  switch  detection,  nr", 

"SSDR  did  not  give  OP  COMPLETE  within  the  allotted  time,  nr", 
"SSDR  reported  OP  COMPLETE,  nr", 

"Mission  abort  inferred,  nr", 

"SSDR  ON  command  issued,  n  r", 

"SSOR  ON  command  succeeded,  n  r", 

"SSDR  ON  command  failed,  n  r", 

"SSDR  OFF  command  issued,  nr", 

"SSDR  OFF  command  succcecd.  nr", 

"SSOR  OFF  command  failed,  nr", 

"VCO  OFF  command  issued,  n  r", 

"VCO  OFF  command  succeeded. n  r", 

"VCO  OFF  coBSsand  failed,  nr", 

"VCO  ON  command  issued,  n  r", 

"VCO  ON  command  succeeded,  n  r", 

"VCO  ON  cosesand  failed,  n  r", 

"A/0  OFF  command  issued,  nr", 

"A/0  OFF  cossnend  succeeded,  n  r", 

"A/0  OFF  command  failed,  n.r", 

"A/D  ON  command  issued,  nr", 

"A/0  ON  command  succeeded,  n  r", 

"A/0  ON  command  failed,  n  r", 

"MATCHED  FILTER  OFF  command  issued,  nr", 

"MATCHED  FILTER  OFF  command  succeeded,  nr", 

"MATCHED  FILTER  OFF  command  failed,  nr". 


■*/ 
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"MATCHED  FILTER  ON  conmand  issuKl.  nr", 

"MATCHED  FILTER  ON  command  succeeded,  nr", 

"MATCHED  FILTER  ON  command  failed,  nr", 

"BUBBLE  MEMORY  HEATER  OFF  command  issued,  nr", 

"BUBBLE  MEMORY  HEATER  OFF  command  succeeded,  nr", 

"BUBBLE  MEMORY  HEATER  OFF  command  failed,  nr", 

"BUBBLE  MEMORY  HEATER  ON  conmand  issued,  nr", 

"BUBBLE  MEMORY  HEATER  ON  command  succeeded,  n  r", 

"BUBBLE  MEMORY  HEATER  ON  conmand  failed.. nr", 

"READ  A/0  command  issued,  n  r", 

"Experiment  terminated. ' n  r", 

"User  interrupted  the  wait  for  APU  detection  n  r.", 

"Invalid  conmand.  n  r", 

"Launch  occurred  before  the  last  program  initialization,  nr", 
"RECORD  mode  command  to  SSOR  succeeded,  n  r", 

"RECORD  mode  command  to  SSOR  failed,  nr." 

)» 

printf  ( ^.lessagelevent  ]  )> 

) 


/«  This  routine  removes  power  from  any  relays  kdiich  have  it,  and  logs  the 
fact.  */ 

void  shut_down(  void ) 

{ 

char  power_porti  /*  Holds  the  status  of  the  power  subsystem.  */ 
power_port  *  power_statusl 

/*  Remove  power  from  all  subsystems  which  currently  have  power.  */ 
if  (SSOROFF  A  power_port ) 

logevent(power_write(SSDROFF)  ?  CSOFFSSDR  :  CF0FFSS0R)» 
if  (VCOOFF  A  power_port ) 

logevent(power_write( VCOOFF )  ?  CSOFFVCO  :  CFOFFVCO)> 
if  (AOOFF  A  powcr_port ) 

logeventt  power_write(  AOOFF  t  ?  CSOFFAO  :  CFOFFADU 
if  (MATFOFF  A  power_port ) 

logevent(power_write(MATFOFF )  ?  CSOFFMATF  :  CFOFFMATF)> 
if  1 HEATOFF  A  power_port 1 

logevent(power_write(HEATOFF)  ?  CSOFFHEAT  :  CFOFFHEAT)> 

) 


/•  This  routine  removes  power  from  any  relays  which  have  it.  It  does  not 
log  the  fact.  »/ 
void  shut_down_no_log(void) 
t 


char  power_portt  /*  Holds  the  status  of  the  power  subsystem,  a/ 
power_port  =  power_status( )» 

/•  Remove  power  from  all  subsystems.  •/ 
if  ISSDROFF  A  powor_port I 
power_write( SSDROFF ) > 
if  I VCOOFF  A  power_port) 
power_wr i tel VCOOFF ) } 
if  (ADOFF  A  power_port ) 
power_write( ADOFF ) » 
if  (MATFOFF  A  power_port ) 
power_write( MATFOFF ) \ 
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} 


if  IHEATOFF  (  paMar_port ) 
pOM«r_wri't«(  HEATOFF )  \ 


/»  This  routirw  ssts  tha  SSDR's  mods. 

/*  "moda"  is  a  eodad  SSOR  moda.  Saa  fila  “vibro.h".  »/ 
char  ssdnsodalchar  noda) 


inf  it  /a  A  countar.  */ 

char  sfafust  /*  Haxadacimal  status*  usad  for  dabugging.  */ 

/*  Rapaat  tha  folloMing  coda  savaral  timas  if  tha  SSDR  doas  not 
immadiataly  appaar  to  ba  succassful.  a/ 
for(i=Oii  <  TRIESt+'t'i  )  < 

output! SSOROUTtinodalt  /a  Output  a  moda  command  to  tha  SSDR.  */ 

/a  Wait  for  tha  SSDR  to  respond,  a/ 
delay! 2 )t  /a  Delay  2  x  10  ms  to  gat  a  valid 
status,  a/ 


status  =  ssdr_statusl )i 
if  ! status  ==  NORMOP)  { 

/a  Adding  1  to  a  moda  gives  tha  coda  for  a  successful  oparation.  a/ 
printf!"SSDR  raturnad  NORMOP  in  rasponse  to  command  OxXx.  nr"* 
moda  I ) 

return! TRUE )» 

J 

/a  The  SSOR  did  not  confirm  tha  proper  mode  was  sat. 

Try  again.  After  you  give  up  in  disgust*  signal 
failure  by  returning  FALSE,  a/ 

} 

printf!"SS0R  did  not  return  NORMOP  in  response  to  command  Ox^x.  nr"*moda)! 
return! FALSE ) k 


/a  This  routine  gets  tha  SSDR's  status,  a/ 
char  ssdr_status! void) 

{ 


return!  irsKit!  SSDRIN ) ) ) 

} 


/aaaaaaaaaaaaaaaaaaaiBaBaaaBBaaBaaaaaaaaaaaaaaaaaaBaaaaaaaaaaaaaaaaaaaaaaMaa/ 
/•  This  function  ratums  TRUE  if  tha  power  sijpply  voltages  are  too  low) 

FALSE*  otherwise.  »/ 
char  voltagas.loMi void ) 

< 

int  voltage)  /a  Holds  tha  voltage  in  hundredths  of  a  volt.  «/ 

ehar  addata)  /«  Holds  the  voltage  as  read  by  tha  A/D.  «/ 

/a  Raad  in  tha  voltage  on  tha  lOV  bus.  a/ 
addata  •  ad_raad(V0LT2)) 

/•  Convert  to  hindradths  of  a  volt.  •/ 
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voltage  ■  adtointtaddatatMULT.lOV)! 
if  (voltage  <  MIN_VOLTA6E_10 )  < 
retum(  TRUE ) » 

} 

retum(  FALSE )  t 

} 


char  via_launchad(  void ) 

char  portdatak  /*  Holds  tha  port  data.  «/ 

/*  Check  to  see  if  the  barosMtrie  pressure  switch  tripped.  */ 
baro_switch(  )( 

portdata  >  input(REAOCl 

if  ((VIB_ON  I  BARO.ON)  A  portdata)  < 

printf(  "Launch  detected.  Turning  matched  filter  off.  nr")t 
logevent(OLAUNCH)t 

logevent(power_write(MATFOFF)  ?  CSOFFMATF  :  CFOFFMATF)t 
return  (OLAUNCH)i 

) 

return) FALSE )( 

) 


Q.  FILENA.ME  FPUTC.C 

/*  fputc.c  */ 

((include  "inout.h" 

((include  "vibro.h" 

((include  "expmnt.h" 

((include  "newio.h" 

int  fputeC int  chr>  void  »device)) 

/*  Bit  0  of  the  serial  port  is  TRUE  if  the  serial  port  is  ready  to  write 
a  character (  FALSE  otherwise. 

Bit  1  of  the  serial  port  is  TRUE  if  the  serial  port  is  ready  to  read 
a  character}  FALSE  otherwise.  •/ 
struct  rs232c  < 

unsifted  int  ;6) 
unsigned  int  read_ready : 1 ) 
irtsi^ied  int  write_ready:l} 

)} 

/«  Zepleisantatien  of  fputo(  )  as  dasoribed  in  the  Uhiware  CeaA>iler  Manual. 
For  tha  NSC800  controller*  there  is  only  one  valid  output  devicOf  namely 
the  RS252C  tensinal.  Tha  variable  "davioe"  is  therefore  ignored. 

This  module  must  be  place  in  uiilib  libo.a  using  the  uar.exe  utility. 

int  fputo( int  chr*  void  edevice) 

< 
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struct  rsZSZc  portdatsi 
char  port_status) 

/»  Allow  tha  usar  to  intarrtpt  tha  display  of  data  by  usa  of  control 
characters.  */ 
allow_ctrl_intarruptsl 

/»  Tha  UNZHARE  manual  spacifias  that  this  function  must  ratum  -1 

if  it  cannot  output  a  character.  If  there  is  no  terminal  attachadr 
this  is  tha  casa.  »/ 
if  ( 'chacKprtC )) 
ratum(-l)> 

do  < 

/»  Kaap  getting  tha  status  information  for  tha  RSZSZC  data  port 
intil  it  is  ready  to  accept  data.  »/ 
port_status=input( PRTCTRL ) t 
portdata  *  *( struct  rsZSZc  a)  tport_statusi 
}  while  ( !portdata.writa_ready ) > 

/»  Otherwise >  output  the  character  and  return  it.  »/ 
output(  PRTDATAil  char )  chr)> 
raturnt  chr ) t 

} 


R.  FILENAME  GLOBAL.H 

/a  This  file  contains  external  prototyping  declarations  of  data  used  globally 
throughout  tha  control  program,  a/ 

extern  char  prtconnectedi 
extern  char  tempbuffer[PAGELENGTHl» 
extern  struct  datetime  clock > 
extern  struct  idatetime  waketimei 
extern  struct  powor_port_fmt  power_port> 
extern  char  adporti AOPOINTS 1 1 
extern  char  pageO_buffsr(PAGELENGTH ] i 
extern  char  log_buf ferlPAGELENGTH 1 > 
extern  struct  pageOdata  apagazerot 
extern  struct  full.log_paga  *log_pagsi 
extern  char  aadcaptiont It 


S.  FILENAME  GLOBAL.C 

/a  global. e  •/ 

/a  This  fila  contains  the  declarations  of  global  variables  needed  by 
the  control  program,  a/ 

Rincluda  'Vibro.h" 

char  prtoomaotedt  /a  TRUE  if  there  is  a  terminal  attached*  FALSE 

otherwise.  «/ 

char  tampbufferlPAGELENGTH]}  /a  A  temporary  buffer,  a/ 

struct  datetime  clock)  /a  The  most  recently  read  time  will  be 
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ttorad  bar*.  »/ 


•truct  idatstiiM  wakatinwt  /«  THq  most  rmcantly  rsad  intsgmr  vmrsion  of 

tiiM  will  b«  stormd  hero.  */ 


struct  pow«r_port_fmt  pow*r_porti 

/«  This  is  •  list  of  A/D  chanrwls  in  us«>  and  what  thay'ra  usad  for. 

Maka  sura  AOPOINTS  >  tha  nsmbar  of  transducars  in  usa.  •/ 
char  adportlADPOlNTSl  «  < 

VOLTO,  VOLTl,  VOLTZ, 

TEMPO,  TEMPI,  TEMP2,  TEMPS,  TEMP4,  TEMPS,  TEM»6 

)» 

char  paga0_buffarl PAGE LENGTH  It  /»  A  buffar  for  bubbla  wamory  paga  0.  */ 

char  log_buffar(PAGELENGTH]t  /*  A  buffar  for  bubbla  mawory  log  data.  */ 

struct  pageOdata  apagezarot  /•  A  pointer  to  tha  paga0_buf far .  •/ 

struct  full_log_page  *log_pagat  /«  A  pointer  to  tha  log_buffar.  •/ 

/*  The  following  captions  should  match  tha  A/0  port  assignments, 
in  order.  See  the  vibro.h  header  fila.a/ 
char  «adcaption[ ]  =  < 

•■♦20V  Bus", 

"-20V  Bus", 

"+10V  Bus", 

"T ,  shelf  above  BMC" , 

"T ,  underside  of  speaker", 

"T ,  shelf  above  batteries", 

"T ,  batteries", 

"T »  controller  backplane", 

"T,  card  8  of  BMC", 

"T,  card  9  of  BMC" 

)t 


T.  FILENAME  INITIAL.H 

/*  This  file  contains  external  prototyping  decalarations  for  all  ftnetions 
in  "initial. c".  «/ 

extern  void  initharcfc4ara(void)i 


U.  FILENAME  INITIAL.C 

/»  initial. c  •/ 

Gincluda  "vibro.h" 

Bincluda  "inout.h" 

Gincluda  "nawio.h" 

void  ini thar(b<are(  void 


/*  This  routine  initializos  tho  NSC810A  ports.  »/ 
void  ini thsrdMsroC void) 


output! MORI >0x00 ) ) 

output!  00RAl,0xff  )| 

output! DDR81 >0xf f ) » 

output! ODRCl >0x30 )t 
output!  TNOl  >0x00)  I 
output! TMOl >0x25 ) t 

output! TOLBl >0x07 ) i 
output! TOHBl >0x00 ) | 


output! ST ARTOl >0x00 )) 
output! M0R2 >0x00 )> 

output! 0DRA2 >0x00 )t 

output! DDRB2  >0x00 ) > 

output! DDRC2, 0x31 )» 
output! TM02, 0x00 )» 
output! TM02  >0x25 ) | 

output! T0LB2  >0x01 ) } 
output!  T0HB2  >0x00)  I 


/•  A  0x00  in  tho  Hoda  Definition  Register 
of  NSC810  B1  puts  port  A1  into  basic  I/O 
siode.  a/ 

/»  Set  port  A1  to  output. 

A1  is  used  to  output  oossnend  codes  to 
the  SSOR.  a/ 

/a  Set  port  B1  to  output. 

B1  is  used  to  sand  cowsend  codes  to  the 
power  sUbsyste*.  a/ 

/a  Set  port  Cl  to  input/output. 

Bits  ere  defined  in  vibro.h  a/ 

/a  Stop  tisier  0  of  NSC810A  Bl.  Vou  Must  do  this 
before  changing  the  timer's  sioda.  a/ 

/a  Set  timer  mode  to  generate  square  waves 
without  pre~scaling>  and  with  single- 
precision  selected>  meaning  only  the  low- 
order  byte  is  ever  read,  a/ 

/»  Set  low-order  end  high-order  byte  for  timer.  »/ 
/«  The  mocKjlus  is  thus  7.  After  2a!7«l) 
cycles >  the  timer  is  reloaded.  Since  the 
NSC800  clock  has  a  frequency  of  4.9152  Hhz> 
and  this  is  divided  by  2>  the  timer  produces 
one  pulse  every  6.51  mus>  for  a  153.6  KHz 
signal.  This  signal  is  fed  to  the  UART  where 
it  is  divided  by  16  to  give  a  9600  BAUD  clock 
for  serial  communications,  a/ 

/a  Restart  timer  0  of  NSC810A  Bl  by  writing 
anything  to  it.  a/ 

/a  A  0x00  in  the  Hoda  Definition  Register 
of  NSCBIO  B2  puts  port  A2  into  basic  I/O 
mode .  »/ 

/a  Set  port  A2  to  input. 

A2  is  used  to  reed  status  codes  from  the 
SSDR.  a/ 

/a  Set  port  B2  to  input. 

B2  is  used  to  read  relay  position  codes 
from  the  power  subsystem,  a/ 

/a  Set  port  C2  to  input/output. 

Bits  are  defined  in  vibro.ha/ 

/a  Stop  timer  0  of  NSC810A  B2.  You  isust  do  this 
before  changing  the  timer's  siode.  a/ 

/a  Set  tiiser  smda  to  generate  square  waves 
without  pre-scaling>  and  with  single- 
precision  selectad>  sieaning  only  ttie  low- 
order  byte  is  ever  read,  a/ 

/»  Set  low-order  end  his#»-order  byte  for  tisier.  a/ 
/a  Tho  Modulus  is  thus  1  deeiMol.  After  2a!l«l) 
cycles >  the  tisier  is  reloedod.  Since  the 
NSC800  olooK  has  a  frequanoy  of  4.9152  (Biz> 
and  this  is  divided  by  2>  the  tiiser  proAjoes 
one  pulse  every  1.62B  ssjs>  for  a  614.4  KHz 
signal.  This  si^wl  is  fed  to  the  A/0 
oonverters.  For  a  640  KHz  clock >  tho  A/Ds 
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ou'tputC  STARTOZ  ,0x00  )  > 


will  conplata  a  eonvarsion  in  about  100  mua. 

Ho  ara  not  far  froM  640  KHz,  so  should  gat 
conparabla  psrformanca.  «/ 

/a  Rastart  timar  0  of  NSC810A  R2  by  writing 
anything  to  it.  »/ 
output(BCLRC2,0x30))  /*  Ensura  that  powar  is  not  appliad  to  tha 

bcUila  wawory  and  that  a  rasat  is  appliad  to 
it.  This  should  ba  dona  whan  tha  NSC810  first 
racaivas  powar,  but  wa  laava  nothing  for 
grantad.  */ 


V.  FILENAME  INOUT.H 

/*  This  fila  contains  axtamal  prototyping  daclarations  for  all  functions 
in  "inout.c".  »/ 

axtarn  void  allow_ctrl_intarrupts( void  )l 

axtarn  void  dump  I  unsigned  int  address,  unsigned  int  langthU 

extern  char  gethexC void  I ) 

extern  unsigned  int  gethexint( void ) l 

axtarn  int  gatintl void ) t 

axtarn  int  gatpaganol void ) t 

extern  char  look_ahaad(  char  acharactarU 

extern  char  looK_ahaad_discard( void  )  k 

axtarn  void  portdunpl char  «string)k 

extern  char  tarmin(void)k 

axtarn  void  tastinputt void)) 

axtarn  void  tastoutput(void)) 


W.  FILENAME  INOUT.C 

/*  inout.c  */ 

aincluda  "vibro.h" 

Rincluda  "convert. h" 

Rincluda  "newio.h" 
aincluda  "bU>bla.h" 

Rincluda  “axpsnt.h" 
ffincluda  "global. h" 

Rincluda  "nain.h" 

void  allow_ctrl_intarnz9tslvoid)) 

void  dunplunsi^iad  int  address,  insi^iad  int  length)) 

char  gathax(void)) 

unsigned  int  gathaxint) void)) 

int  gatintivoid)) 

int  gatpagano) void ) ) 

char  looK.ahaadi char  acharactar)) 

cfiar  looK_ahaad_discard(void)) 

diar  termini  void)) 

void  test input I  void)) 

void  testoutputivoid)) 
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/•  cansol*_buff«r  is  sharsd  by  looK_sh*sd(  )  and  tartninf  ).  If  looK_ahaadl  ) 
raads  a  charactar  in>  if  puts  if  in  fha  buffar  and  safs  fha 
console_dafa_avai labia  flag  fo  frua. 
farmin( )  Mill  look  firsf  in  fha  buffar  for 

inpuf  frois  fha  censola.  If  if  finds  any>  if  Mill  saf  oonsola.dafa  fo  falsa 
and  rafum  fha  eharacfar  in  fha  buffar.  OfharMisa  if  will  fry  fo  gaf  a 
characfar  from  fha  consola  in  fha  usual  way.  »/ 
sfafic  char  consola_buffar» 
sfafic  char  consola_dafa_avai labia  >  FALSE > 


/»  This  roufina  procassas  fha  spacial  characfars  CTRL  S  and  CTRL  Y  from 
fha  kayboard.  */ 

void  allow_cfrl_infarrtpfs(void) 
i 

char  conchari  /»  Tha  characfar  of  consola  inpuf  dafa  ifsalf.  */ 

char  char_availablat  /*  TRUE  if  fhara  is  a  characfar  available  for 

inpuf  from  fha  consola (  FALSE  ofharwisa.  */ 

/*  If  fhara  is  a  S  characfar  in  fha  RS232C  inpuf  porf>  fhan  read  if 
in  using  farminl  )  and  loop  unfil  another  S  is  given.  Thus>  S 
serves  as  a  toggle  for  stopping  and  starting  output.  «/ 

/*  See  if  there  is  a  characfar  available* 
and  if  so>  put  if  in  conchar.o/ 
char_availabla  -  look_ahaad( tconchar  It 

if  (char_availabla)  < 
sw ifch( concha r  I  { 
case  CTRLS; 
case  CTRLY: 

/*  Call  farminl  I  fo  empty  fha  buffar  and  handle  fha 
control  character.  */ 
farminl  It 
break t 
default : 
break  t 

} 

J 

} 


/»  This  roufina  procfcjces  a  hexadacimal  dump  of  any  saefion  of  memory.  «/ 
void  duipl unsigned  inf  address*  tnsignad  inf  length  I 
< 

unsiffiad  inf  it  /*  Points  fo  fha  currant  byte  being  duipad.  */ 

char  asciiCOLRIPHIDTHtllt  /*  Contains  fha  ASCII  equivalent  of  each  byte.  •/ 

asciilOUHPMIDTHl  *  NULLt  ftaka  sura  ascii  has  a  null  dalimifar 

fo  look  like  a  C  string,  a/ 

/•  Convert  length  fo  a  mulfipla  of  DUMPHIDTH.  «/ 
length  *  1 1  length  ♦  DUhPHIOTH-1  l/DUMPHIDTH  I  •  DUMPHIDTH t 
for  I  isOii<lengfhti*'»  I  < 

if  1 0»i/CDUMPHIDTH  I  {  /*  Dump  fha  ascii  version  and  start  a 

new  line  every  DUMPHIDTH  characfars.  */ 
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if  (i  >  0)  C 

printf  (  n  r''«ascii  )i 

) 

/*  Also*  dump  thm  currmnt  addrmss.  a/ 
printf("/is:  " >uitoh( addrass^i  ) ) I 

} 

/*  Put  axtra  spacas  in  tha  aiddla  of  aach  lina.  »/ 
if  (0s>iX(0UMPHI0TH/2)  At  0  •>  i;<DUHPWIDTH )  < 
ppintfC  'Ml 

) 

printf (  "Xa  "  ictohl  atchar  a)  (addraaa‘»i))i(  /a  Dump  aach  byta  individually,  a/ 
/a  Insart  tha  currant  charactar  in  tha  string  "ascii". a/ 

/a  If  it's  not  printabla>  raplaca  it.  »/ 
asciiCiXDUMPHIDTH]  s  aichar  a)  (addrass^i )t 

if  (asciiCi;(OUHPHIDTHl  <  SPACE  ||  asciil  i/'OUHPHIOTH  ]  >=  DELETE)  { 
asciiti/DUHPHIDTHl  -  '.'l 

} 

1 

/«  Maks  sura  ascii  is  printed  again  at  tha  and  of  tha  last  lina.  »/ 
if  ( i  >  0)  { 

printf ( "Zs  n  r" lascii ) i 

} 

> 


»««»»«»»««««»«»«««««»»»»»«/ 

/a  This  routina  gats  a  haxadacimal  byta  from  tha  tarminal.a/ 
char  gathax(void) 
int  i ) 

char  stringlHSTRLEN  ♦  11 j 

stringtHSTRLEN)  =  NULL) 
for  (isO)i  <  HSTRLEN)++i)  { 

stringC i  1  =  tolowart tarmin(  ) ) ) 
if  ( string! il  ==  BS)  < 
i  -=  2) 
if  ( i  <  -1)  < 
i  =  -1) 

}  alsa  t 

printf!  "b  b")) 

} 

centinua) 

) 

printf C "Zc" »str ing( i 1 ) l 
if  lstring[il  >*  'a'  At  stringti]  <»  'f') 
continual 

if  Istringlil  >■  'O'  At  string! i  1  <■  '9') 
continual 
string! i ]  ■  NULL) 
braaki 

) 

ratumi  atohl  string ) )  i 

} 
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/*  This  rouiin*  gats  a  haxadacimal  word  (two  bytas)  from  tha  tarminal.*/ 
unsignad  int  gathaxintlvoidl 
int  it 

char  stringCHEXZNTsrRLEN4l]» 


string[HEXIHTSTRLEN]  s  NULLt 
for  (icOti  <  HEXlNTSTRLENt«4i)  < 
stringiil  -  tolowar(  tarmint  ) )| 
if  Istringtil  ss  BS)  < 
i  -s  2t 
if  (i  <  -1)  { 
i  =  -It 
}  alsa  < 

printff’b  b")t 

} 

continuat 

) 

printf ( "Xc" >string[  i 1 ) t 

if  (stringtil  >=  'a*  stringtil  <=  'ft 
continual 

if  (stringtil  >=  '0*  it  stringtil  <=  '9') 
continual 
string! i 1  =  NULLi 
break l 
J 

return! atohaxinti string ) ) i 


) 


/»  Gat  an  integer  from  thu  terminal.  »/ 
int  gatintivoid) 

I 

int  i  I 

char  str ingtSTRLEN 1 1 

string! STRLENl  =  NULLi 
for  (i^Oii  <  STRLEN|t*i)  < 
stringtil  s  termini )i 
if  (stringtil  ss  BS)  i 
i  -■  2t 
if  (i  <  -1)  < 
i  *  -It 
}  alsa  < 

printf!  "ib  b"M 

} 

continual 

} 

printf!  “Xo’Sstringl  i  1  It 
if  (stringtil  <  *0'  ||  stringtil  >  '9')  < 
stringtil  >  NULLt 
break! 

) 

J 
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ratuml  atoif  string ) )  i 


} 


int  gatpageno(void) 

< 


int  pagat 

char  sISTRLENli  /«  Storage  for  itoal  I.  »/ 

itoalMAXPA6EtS)> 

printf ("Input  tha  Ixiibla  maamry  paga  nunbar  (0-Xs  dacimal):  ">s)( 
Mhila  (TRUE)  < 

paga  ■  gatintC  It 
printf I" n  r“)i 

if  (paga  >■  0  M  paga  <»  MAXPA6E  I 
braaK  t 

itoa(MAXPAGE>s)t 

printf  ("Paga  must  ba  in  tha  ranga  tO-'/.s  dacimal):  ">s)t 


raturn( page  1 1 

1 


/*  This  function  checks  to  sea  if  a  character  is  available  through  termini  ). 

It  places  the  charactert  if  anyt  in  the  location  pointed  to  by 
'character'.  It  returns  TRUE  if  there  was  a  character*  FALSE  otherwise.  */ 
char  looK_ahead( char  «character ) 

< 

/*  If  there  is  no  terminal  attached*  return  FALSE.  •/ 
if  ( !checkprt(  1 1  < 
return! FALSE ) > 

) 


/»  If  the  buffer  is  already  full*  return  it's  contents* 
but  don't  empty  it.  */ 
if  I console_data_available I  (, 

*character  =  console_buf far  I 
return! TRUE  I J 

) 


/*  Check  the  RS232C  port  to  see  if  there  is  data  available. 

Bit  1  will  ba  1  when  data  is  present.  »/ 
if  ( inputIPRTCTRLI  (  PRTROY  1  < 

/*  If  there  is  data*  store  it  in  tha  buffer  and  let  termini  )  know 
about  it  by  setting  the  console_data_avai labia  flag.  */ 
acharacter  -  consola.buffer  *  inputlPRTDATAIi 
return! consola_data_available  >  TRUE  )| 


} 

return! FALSE  It  /«  No  data  was  present.  «/ 


1 

. . . 

/•  This  routine  cheeks  to  sea  if  a  character  has  bean  entered  frost  tha 
keyboard.  If  so*  it  discards  tha  character  and  returns  TRUE.  If  not* 
it  returns  FALSE.  */ 
char  look_ahaad_discard! void! 

< 

if  ! looK_ahaad! ! char  •)  NULL))  < 


207 


tarminl  )t 
ratupn( TRUE )  > 

}  als« 

ratum(  FALSE  ) » 

) 


/*  This  function  obtains  a  charactar  from  tha  kayboard.  */ 
char  tartnin(void) 

< 

static  char  alloM_manu_call  =  TRUEi 

•'*  'allow_manu_call'  is  trua  if  manu(  )  can  ba  callad  from  tarmini  )> 

FALSE  otharwisa.  It  can  ba  callad  from  tarmini )  onca)  subsaquantly> 
it  must  first  ratum  control  to  tarmini  ).  Thus*  ona  racursiva  antry 
into  manul  )  is  parmittad  at  a  tima.  Tha  a>q>arimant  can  ba  monitorad> 
but  only  at  ona  subordinata  calling  laval  and  no  mora.  */ 

char  waiting_for_ctls I 

/a  This  variabla  is  trua  if  an  odd  number  of  CTRL-S  characters  has 
been  accepted.  No  characters  can  be  accepted  from  tha  keyboard 
until  an  even  number  of  them  have  been  received.  However^  CTRL-Y  can 
ba  acceptadt  in  which  case  manul  )  will  be  called  at  once.  «/ 

char  ctrl_valid_data j  /»  This  is  TRUE  if  look_aheadl  )  already  filled 

tha  buffer!  FALSE  otherwise.  */ 

waiting_for_ctls  =  FALSE! 
ctrl_valid_data  «  consola_data_availabla! 

/«  Loop  continuously  until  an  acceptable  charactar  has  been  received.  */ 
while  I  TRUE)  < 

/*  If  the  buffer  is  empty>  then  wait  for  a  character  to  ba  entered. 

It  could  have  bean  filled  by  looK.aheadI  ).*/ 
if  I !console_data_availabla )  t 
while  (TRUE)  < 

Check  the  RS232C  port  to  see  if  there  is  data  available. 
Bit  1  will  be  1  when  data  is  present.  Hait  for  data.  »/ 
if  I inputlPRTCTRL )  (  PRTRDY  )  < 

consola_buf far  =  inputIPRTDATA)! 
break ! 

) 

J 

/•  Now  that  console  data  has  bean  read>  sat  the  availability  flag 
FALSE  so  that  if  it  bacoaws  necessary  to  road  another  charactar > 
you  can  do  so.  */ 
consola_data_availablo  «  FALSE! 
switch  iconsola_buffar)  < 
case  ICTRLS): 

/»  Toggle  tha  waiting_for_ctls  flag.  As  long  as  this  flag 
is  truOf  you  can't  gat  out  of  termini  ).  */ 
waiting_for_ctls  ■  !waiting_for_ctls! 
if  1 1 !waiting_for_ctls  )  <S  ctrl_valid_data ) 
retumi  consola_buf  f  ar ) ! 
break ! 
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4 


« 


casa  (CTRLY): 

/«  You  can  axacuta  a  CTRL-Y  avan  if  a  CTRL-S  is  panding, 

Tha  affact  is  fo  cancal  tha  CTRL-S.  */ 
wai'ting_for_ctls  =  FALSE) 
if  lalloM_manu_call )  { 

allow_manu_eall  ■  FALSE) 

/»  Tall  manuC )  not  to  start  tha  axparimant.  This  is 

only  parmissibla  whan  mainC  )  is  tha  calling  function.  «/ 
manul 'EXPERIMENTOK )) 
allow_manu_call  =  TRUE) 

} 

if  (ctrl_valicl_eiata) 

ratum(  consola_buf  far ) ) 
braaK ) 
dafault: 

/*  Ignora  this  character  if  you're  waiting  for  a  second  CTRL-S.  */ 
if  (waiting_for_otls >  < 
break ) 

> 

return! console_buf f ar  ) ) 

) 

} 

) 

/»*«««»•««»«»«»«««»*»»«»»«««»»«»«•««««»»«»«»«««»*««*«««»«««»««»«'«««««»»»»»«•/ 

/*  This  function  allows  tha  user  to  road  data  from  any  port.  */ 
void  testinput(void) 

< 

int  port)  /«  Port  number  to  bo  entered  from  tha  keyboard. »/ 

char  data)  /*  Data  to  be  read  from  that  port.  */ 

printf! "Specify  port  address  to  be  read  tin  hexadecimal);  ")) 
port  =  gethex( ))  /*  Gat  tha  port  address.  «/ 

printf ( " n  r"  I ) 

data  =  input!  port))  /*  Read  from  tfio  port.  •/ 

printfl"Data  from  port  (in  hexadecimal):  Zs n  r",ctoh! data  )  ) ) 

} 


/a  This  routine  outputs  a  character  to  a  specified  port.  •/ 
void  tastoutputl void ) 

{ 

int  port)  /*  Tha  port  address.  •/ 

char  data)  /•  Tha  data  to  be  sent  to  the  port.  «/ 


printf( "Specify  port  address  to  be  written  to  (in  hexadecimal):  ")) 
port  *  gathax( ))  /*  Gat  tha  port  address.  «/ 

printf( "  nr")) 

printf ( "Specify  the  data  to  be  sent  to  tha  port  (in  hexadecimal):  ")) 
data  s  gethax(  )) 
output) port  f data ) ) 
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X.  FILENAME  MAIN.H 


/*  This  fil«  contains  axtamal  prototyping  daclarations  for  all  functions 
in  "main.c".  »/ 

axtam  void  iMmory_dijnp( void )  > 
axtam  char  monutchar  axp«riinant_f lag )  i 
axtam  void  program!  void )  i 
axtam  void  tastio!  void)t 
axtam  void  main! void)) 


Y.  FILENAME  MAIN.C 

main.c  */ 

ffincluda  "version. h" 
ttinclude  "vibro.h" 

^include  "bubble. h" 

^include  "inout.h" 

^include  "power. h" 

Oincluda  "convert. h" 

^include  "initial. h" 
ffincluda  "clock. h" 

^include  "newio.h" 
include  "global. h" 
ffincluda  "expnnt.h" 

void  memory.cKjnp!  void  1 1 
char  menu! char  experiment_flag)i 
void  testiol void  I) 
void  main! void)) 

/jHHHHUnummoiimKKKajHHmaaaaainniiKaaKimasmKainiMmnnHHunHUHnnHHUHnmawmmwsii/ 

/»  This  routine  lets  the  user  produce  memory  dumps  for  any  section  of  memory.*/ 
void  memory_dutnp(  void ) 

{ 

unsigned  int  address)  /•  Hill  hold  the  starting  address  of  the  dump.*/ 
unsigned  int  length)  /*  Hill  hold  the  number  of  bytes  to  dump.*/ 
while  !TRUE)  { 

printf! "Please  specify  address:  ")) 
address  s  gethexint! )) 

printf !"  n  rPlease  specify  nunber  of  bytes  to  dump  !0  to  quit);  ")) 
length  *  gethexint!  )) 
printf!"  nr")) 
if! length  0 ) 
break) 

dump! address  > length ) ) 

} 

> 


/*  This  routine  is  the  highest  level  of  all  the  diagnostic  menus. 

It  will  not  permit  the  experiment  to  be  rxn  unless  the  experiment. flag 
is  TRUE.  */ 

char  menu! char  experiment.flag ) 

{ 
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char  data) 

int  i  > 

char  acMata) 

int  value 1 

Nhila(TRUE)  < 
varsioni )> 
printf  ( ", 

A  Softwara  rasat.  n  r\ 

B  Raaltime  clock  functions. ',n  r\ 

C  Power  relay  switching  fixtctions.\n\r\ 

0  Bubble  memory  test  fctictians.  n,r\ 

E  A/D  converter  fixwtions. .,n\r\ 

F  Run  experiment,  n  r\ 

6  Perform  port  I/O.  n  r\ 

H  Display  contents  of  controller  memory,  nr; 

I  Examine  or  change  the  data  logged  in  the  bubble  memory,  n  r 
Z  Exit  this  menu,  n  r"  )  l 


/a  A  character  read  from  the  keyboard.  */ 

/*  A  counter.  */ 

/a  A  value  read  from  the  A/D  converter.  »/ 

/a  The  A/0  reading  converter  to  useful  laiits.  a/ 


/a  Read  in  a  character  from  the  keyboard*  convert  it  to  lower  case* 
and  display  it.  a/ 
data  =  tolower( termin(  1 )  ( 
pr intf  (  "’/.c  n  r"  >data  )  t 
switch  (data!  < 

case  'a':  /a  To  perform  a  software  reset*  jump 

to  address  0.  a/ 


asn(  "  jp  0"I| 
break > 
case  ' b ' : 

•  rtcl  )J 

break! 
case  ' c ' : 

pwrcnt(  )  t 
break  > 
case  'd': 

bubmenu(  )( 

break i 
case  ' e ' : 


/a  Call  the  real  time  clock  functions,  a/ 


/a  Call  the  power  control  functions.  »/ 


/a  Call  the  bubble  memory  testing 
functions.  »/ 

/a  Display  the  A/D  data.  */ 


for  »i=0ji  <  ADPOINTS!++i)  C 

addata  ■  ad_readla(^rt[il)> 

pr intf ( "Z-24s*/3 . Ods" *adceptionI i 1 *addate ) > 

/•  If  i  <s  2*  then  the  A/D  reading  is  a  voltage,  a/ 
if  (i  <■  21  { 

value  •  adtointC addata *(i«>Z)?HULT_10V  :  hULT_20V)) 
printf("Xc/2.0d.Z02.0dV  i«»l  )?•-•:’♦• * 
value/100  *valueX100 ) > 

/a  Otherwise*  the  A/0  reeding  is  e  tempereture.  »/ 

}  else  < 

value  a  adtoint(addsts*MULT_TEnP)! 
printf("Z6.0<K  "*velueU 
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/*  Print  two  points  p«r  lino.  */ 
if  1(0  Is  i  X  2)  II  i  ss  AOPOINTS  -  1) 
printfl"  nr")j 

} 

braaK ( 

easa  'f:  /a  Exaeuta  tha  axparisiant>  uilass  it 

is  currantly  in  a  suspandad  stata.  a/ 

if  laxparimant.flag)  < 
axpnntc  )t 

}  alsa  { 

printfCYou  cannot  rest  tha  axparimant  functions  whila  \ 
axacution  is  suspandad  with  \Y.,nrExit  this  manu  and  try  again,  nr'*  )> 

braaki 
casa  'g': 

tastiof 
braaki 
casa  'h': 

inemory_duiiip(  1 1 


braak i 
casa  ' i ' ; 

log_manu(  )  i 


braak i 
casa  ' z ' : 

ratumi 

dafault: 

printfC'Usa  a  valid  lattar  plaasa!  nr")i 

) 

J 

> 

/>H><nnnnnnnnnnHnnnHnnnHnnHta»»<nnnnn>i«>in>ainm<nnnnHtaa«Hnnnn>»<nnnnnK»«a<nnt<nt««/ 
/a  This  routina  allows  you  to  output  data  manually  to  any  port*  or  to  raad 
data  from  any  port,  a/ 
void  tastio(voidl 
C 

char  datai  /a  A  character  antarad  from  tha  keyboard,  a/ 

/a  Rapatitivaly  display  tha  following  manu  until  ohoioa  Z  is  made,  a/ 
whila  (TRUE)  < 
printf ( 

"\n\rHanual  port  I/O  functions.  Pick  ana!  n  r\ 

A  Input,  n  r. 

B  Output . '  n  r', 

Z  Return  to  previous  manu.  ,n.r")l 

/a  Road  a  character  from  the  keyboard*  convert  it  to  lower  ease* 
and  display  it.  a/ 
data  ■  tolowar( terminC J  li 
printfC'Zc  n  r"*data)i 
switch! data)  t 


/a  Enter  the  routine  which  reads  from  and 
writes  to  any  port.  */ 


/a  Enter  tha  routine  which  displays  the 
contents  of  selected  portions  of 
memory .  a/ 

/a  Entar  tha  routine  which  permits  the 
contents  of  the  bubble  memory  log  to 
be  modified,  a/ 
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cas*  /«  Entar  tha  function  Mhich  allowa  the 

uaar  to  raad  data  from  a  port.  */ 

tastinput(  )| 
break | 

casa  'b':  /a  Entar  tha  function  Mhich  allows  tha 

usar  to  writa  data  to  any  port.  */ 

tastoutputi  )l 
braaki 

casa  'z':  /*  Quit.  »/ 

ratumi 
dafault: 

printfC'Usa  a  valid  lattar  plaasa.  n  r" 
braaki 

} 

) 

} 

/a  Tha  C  program  begins  hara.  This  routine  gats  control  from  tha  assembly 
language  program  which  resides  at  address  0.  «/ 
void  main(void) 

/a  Make  sure  that  each  of  these  pointers  is  intializad  to  point  to  tha 
same  memory  as  tha  corresponding  buffer.  Thus  tha  same  data  can  be 
accessed  either  as  a  list  of  characters  la  buffer)  or  as  a  structure 
( if  the  contents  need  to  be  accessed  individually.  )  a/ 
pagezero  =  (struct  pageOdata  a)  page0_buf far i 
log_page  =  (struct  full_log_paga  a)  log_buffar) 

/*  Initialize  tha  system  ports,  a/ 
initharc^arel  )| 

/a  See  if  thera  is  a  terminal  attached.  If  so>  turn  off  any  subsystems 
which  are  currently  on  and  enter  tha  menu  diagnostic  system,  a/ 
if  (prtcomected  =  checkprt(l)  < 
shut_down_no_log(  1 1 
while  (TRUE)  < 

menu!  EXPERIhENTOI^ )  l 

} 

/a  If  there  is  no  terminal  attached^  we  must  be  in  space>  so  run  the 
experiment,  a/ 

)  else 

expmnti  ))  /»  Rwn  the  experiment,  a/ 


Z.  FILENAME  MBRK.S 

I  i^rk.a 


mbrkl  )  function  for  use  with  malloe(  )  end  ealloci  1. 

File  ''spec"  declares  a  single  aection  of  RiQli  HRAMSZ  bytes  longi 
to  use  for  memory  allocation*  and  START  in  file  "start. asm" 
initializes  MBRKPTR  to  point  to  that  memory. 


global 

abrR .MBRKPTR ,MRAMSZ 

option 

long =4 

> 

assuma  longB4  bytas 

ragion 

coda 

mbrK 

push 

ix 

t 

char  ambrkl  long  siza>  long  araalsiza  )t 

Id 

ix,0 

add 

ix>sp 

1 

( ix+4iS>A»7):siza>  ( ix48>9):raalBiza 

Id 

da,(hBRKPTR) 

t 

rotum  valua  is  addrass  of  aamory  saction 

Id 

a>d 

or 

a 

jr 

z>out 

> 

zaro  siaans  aawory  saction  is  in  usa 

Id 

a  1 1  ix'f  6 ) 

or 

(ix+7) 

3r 

nz >out 

i 

nonzaro  naans  aora  than  64K  raquastad 

Id 

c>(  ix«4) 

» 

raquastad  'siza'  to  be 

Id 

bt(  ix+51 

Id 

hl,HRAHSZ 

1 

chack  if  'siza*  bytas  ara  availabla 

1 

assuHMS  MRAHSZ  is  lass  tKMn  64K 

or 

a 

1 

claar  tha  carry  flag. 

sbc 

hlibc 

jr 

c>out 

Id 

bctO 

t 

mark  mamory  saction  as  usad 

Id 

(MBRKPTR),bc 

» 

da  still  holds  formar  MBRKPTR 

Id 

1>(  1X48) 

) 

gat  tha  pointer  to  ‘raalsiza* 

Id 

h»(  ix+9 ) 

Id 

(hl),lo  HRAMSZ 

) 

writs  back  actual  siza  of  manory  saction 

inc 

hi 

Id 

IhD.hl  MRAhSZ 

inc 

hi 

Id 

(hl),0 

inc 

hi 

Id 

(hl).O 

3*“ 

rat 

) 

da  is  tha  ratum  valua 

out: 

Id 

da,0 

) 

out  of  mamory,  return  zaro  pointer 

rot: 

Id 

sp>ix 

pop 

ix 

rat 

AA.  FILENAME  NEWIO.H 

•xtam  char  input!  char  portli 

axtam  void  outputlehar  port>char  data)i 


AB.  FILENAME  NEWIO.S 

t  naMio.a 

axport  input >  output 
rogion  ooda 

I  ohar  inputlchar  port)| 
input: 

puah  ix  )Tharo  ara  no  local  variablaa. 

Id  ix>0 
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add 

ix>sp 

Id 

e>(  ix+4) 

(Put  port  address  in  register  c. 

in 

a>(c) 

(Get  the  data  from  the  port. 

pop 

ix 

(Restore  ix  to  the  value  it  had  before  this 
(function  was  called. 

ret 

>  void  output  (char  port,  char  datali 


output: 

(xjsh 

ix 

Id 

ix>0 

(There  are  no  local  variables. 

add 

ix,sp 

Id 

c,(  ix*4) 

(Put  port  address  in  register  c. 

Id 

a  1 1 ix«6 ) 

(Put  data  in  register  a. 

out 

lc)ia 

(Ifrite  the  data  to  the  port. 

pop 

ix 

(Restore  ix  to  the  value  it  had  before  this 
(function  was  called. 

ret 

AC.  FILENAME  POVVER.H 

/*  This  file  contains  axtamal  prototyping  doclarations  for  all  functions 
in  "power. c".  */ 

extern  char  power_status( void  I ) 
extern  char  power_write( char  comnandlt 
extern  void  pwrcnt(void)t 


AD.  FILENAME  POWER.C 

/a  power . c  »/ 

^include  "vibro.h" 
include  "bubble. h" 

^include  "convert. h" 
ttinclude  "inout.h" 

^include  "delay. h" 

(^include  "expmnt.h” 

((include  "nowio.h" 

((include  "global. h" 

char  poMer_status(void)t 
char  power_write(char  cosanndli 
void  pwrcnt(void)> 

. . . 

/*  This  routine  gets  the  status  free  the  power  boerd.  •/ 

char  power_statusl void ) 

{ 

} 


rotum(  ir^tl  PONERIN 1 )  | 


/*  This  routirw  s«nds  comnands  to  th*  poMor  board.  */ 

char  poMOr_writalchar  command) 

< 

int  it 

char  status) 

char  oncommand)  /*  TRUE  it  command  is  an  ON  commandt 

FALSE  otharwisa.  */ 

char  ralayon)  TRUE  if  tha  indicatad  ralay  is  on> 

FALSE  otharwisa.  •/ 

/»  Try  to  sand  tha  command  to  tha  powar  board. 

Ratum  TRUE  if  succassful.  Ratum  FALSE  aftar  you  giva  up 
in  disgust.  */ 
fori i=0)i<TRIES)i+*)  t 

output! POHEROUT  tcommand ) ) 
output! BSETCl ,PWRSTROBE ) ) 
dalaylPHRDELAY)) 
output! BCLRCl ,PMRSTROBE ) ) 

delay! PMROE LAY))  /»  Wait  PHROELAY  x  10  ms  for  tha 
relays  to  respond.  */ 

/*  The  command  is  intended  to  turn  a  relay  on  only  if  tha 
last  bit  is  sat  111.  »/ 
oncommand  =  ONBIT  A  command) 
status  =  NOPOWER  |  power_status!  )) 

/*  To  see  whetltar  tha  indicatad  relay  is  on> 
sea  whether  only  the  status  bit  in  t)w 
relay's  assigned  bit  position  is  a  zero.  If  it  is>  ttien 
that  relay  is  on.  */ 
ralayon  s  status  A  command) 

/»  If  tha  relay's  position  matches  that  commanded*  tlian 
log  a  successful  setting  of  the  ralay. 
if  II oncommand  AA  ralayon  I  ||  I ! oncommand  AA  ! ralayon))  < 
return! TRUE  ) ) 

1 

printf  I  "Trying  again  to  switch  relays,  nr")) 

) 

/*  If  you  got  this  far*  then  the  relay's  position  did  not  match 
that  commanded*  so  log  a  failure.  •/ 
ratum!  FALSE  )) 


. . . 

/a  This  routine  sands  commands  to  tha  power  board.  •/ 

void  pwrcntivoid) 

< 

char  data)  /»  Data  from  tha  Keyboard.  */ 
static  int  relay! 1  *  < 

SSDRON,  SSDROFF,  VCOON*  VCOOFF*  ADON,  ADOFF, 
MATFON*  MATFOFF*  HEATON*  HEATOFF 

}) 


while!  TRUE)  < 


printf ( n  pPOHER  SNITCH  CONTROL,  n  r  n  r\ 

A  •  SSOR  on.  n  r\ 

B  «  SSOR  off.  n  r 
C  ■  VCO  on.  n  r 
0  »  VCO  off.  nr, 

E  ■  A/0  on.,n\r\ 

F  »  A/0  off.  n  r\ 

6  »  HATCHEO  FILTER  on.  n  r\ 

H  »  HATCHEO  FILTER  off.  nr\ 

X  ■  HEATER  on.\n  r\ 

J  ■  HEATER  off.  nrv 
K  B  REAO  poMor  statuo  porf.\n.r\ 

Z  >  Back  -to  fha  HAIN  MENU.\n,r‘‘ l» 

data  a  toloMorl  tar«iin(  1 )} 

pr intf  (  “‘/.G  n  r"  tdata ) ) 

if  (data  'a'  <A  data  <a  'j')  < 

if ( fpoMor.writaC  ralay(data-'a* ) ) I 

printf ( "PoMor  control  command  failed.  nr'')( 

}  also  { 

switch  (data)  < 
caso  'K': 

printf)  n  r"  >ctoh( powar_statos)  ) ) )  > 
broaKt 
case  'z' ; 

return t 
default; 

printfC'Use  a  valid  letter>  please,  nr*')) 
break ) 


AE.  FILENAME  START.S 


February  19>  1988  start. a 

This  startup  code  initialises  internet  vaotors  and  runs  START  at 
reset 

to  initialize  RAH  and  call  the  user  fuzietion  main!  ). 

The  cofipanion  link  specification  file  is  "spec"  which  defines 
many  of  the  isported  syitels.  Also  see  file  "nfcrk.asm”  for  the 
■brki  )  fiswtion  if  you  want  to  use  mallool  )  or  ealloci  ). 

The  program  is  adapted  from  an  exasple  given  in  the  UNINARE 
manual >  Cospilar  section*  pp.  13-15. 


export  START. HBRKPTR 

import  main.STACKTOP.RAHOATA.ZRAH.ZRAHSZ.IRAH.IRAHSZ.HRAH 
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t  D«fin«  a  variabla  to  track  nemory  allocations  in  nbr-KI  ). 

t  (char  M)  to  availabla  mamory 


region  ram 
MBRKPTR  ds  2 


I  Resat  coda  must  ba  linked  to  address  0. 


region  rttsa't 

Id 

sp,  10  STACKTOP 

)  initial  stack  pointer  (0x10000  as  0) 

jp 

START 

)  initial  execution  address 

org 

0x08 

ARESTART : 

IRESTART  LOCATION  1 

jp 

START 

org 

0x10 

BRESTART : 

(RESTART  LOCATION  2 

jp 

START 

org 

0x18 

CREST ART: 

(RESTART  LOCATION  3 

jp 

START 

org 

0x20 

OREST ART : 

(RESTART  LOCATION  4 

jp 

START 

org 

0x28 

ERESTART: 

(RESTART  LOCATION  S 

jp 

START 

org 

0x2C 

FRESTART : 

(RESTART  LOCATION  C 

jp 

START 

org 

0x30 

GRESTART: 

(RESTART  LOCATION  6 

jp 

START 

org 

0x34 

HRESTART: 

(RESTART  LOCATION  8 

jp 

START 

org 

0x36 

IRESTART ; 

(RESTART  LOCATION  7 

jp 

START 

org 

0x3C 

JRESTART : 

(RESTART  LOCATION  A 

jp 

START 

org 

0x66 

NOFMASKI: 

(NON-NASKABLE  INTERRUPT 

jp 

START 

I  This  coda  can  ba  anyMherai  the  reset  coda  junps  to  it. 

rggion 

code 

START;  Id 

ix,0 

>  and  of  stack  frame  chain 

Id 

hl,MRAH 

(  initialize  memory  allocator 

Id 

(hBRKPTR),hl 

> 

Zero  out  uninitialized  RAM. 

V 
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I  It  is  assunwd  hara  that  ZRAMSZ  >  1  but  this  is  guarantaad 
I  as  long  as  MBRKPTR  (abova)  is  dafinad  in  ragion  ram. 


Id 

hi ,ZRAM 

t  zero  ZRAMSZ  bytas  here 

Id 

(hl)>0 

t  zero  first  byte 

Id 

da>ZRAM+l 

)  rapaatadly  zero  othar  bytas 

Id 

bc>ZRAMSZ-l 

Idir 

i  Initializa  othar  RAM  from  ROM. 


> 


Id 

hl.RAMDATA 

Id 

de,IRAM 

Id 

bcIRAMSZ 

Id 

a>b 

or 

c 

jr 

Idir 

ZiDona 

nona: 


^MWimUKIOKII 

>  Invoka  main(  )  with  no  arguments. 


call 

main 

i 

any  return  value  is  "int"  in  de 

done;  halt 

halt  if  main  returns 

To  vector  an  interrupt 

'to  a 

C  fu^tion>  you  must  go  though 

> 

a  register  save  routine 

like  the  one  shown  hare. 

» 

If  the  " 

-r  axx"  option 

is  being  given  to  the  command  lina> 

> 

then  registers  be'  da' 

and 

hi'  need  not  be  saved  and  restored 

> 

since  the  compiler  will 

make  no  use  of  them.  The  compiler 

i 

does  not 

WWWWWWWWWMM 

use  af  in  any 

case. 

region 

code 

jINTERRUPT 

> 

push 

af 

» 

save  registers 

i 

push 

be 

> 

push 

de 

> 

push 

hi 

> 

push 

ix 

> 

push 

iy 

> 

exx 

> 

push 

be 

> 

push 

de 

» 

push 

hi 

) 

•XX 

) 

call 

efen 

1 

call  soma  C  function 

) 

•XX 

» 

pop 

hi 

> 

restore  registers 

» 

pop 

da 

» 

pop 

be 

> 

•XX 

> 

pop 

iy 

pop 

ix 

pop 

hi 
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»  pop  d* 

l  pop  be 

»  pop  »f 

>  oi 

I  rat  I  ratum  fro*  intarr^it 

AF.  FILENAME  ASM.BAT 

Sram  MaKa  asmsourca  tha  currant  sii>diractory 
cd  vibro  contrlr  asmsourca 
Sram  Assambla  tha  specifiad  sourca  fila 
uaszSO  -c  80  -n  -t  4  -L  Z1 

Sram  Placa  tha  objact  modula  in  tha  objact  stixiiractory 
copy  *.o  vibro  contrlr. objact 
erasa  *.o 

Sram  Place  tha  assembly  listing  in  tha  list  subdirectory, 
copy  *.lst  vibro  contrlr  list 
erase  *.lst 


AG.  FILEN.\ME  ASMLIST.BAT 

Sram  Fill  in  the  symbols  of  the  specified  assembly  listing  fila 
Sram  with  tha  values  given  in  tha  executable  module  u.out. 

Sram  Pipe  tha  completed  listing  to  the  ulist  program  to  give  a 

Sram  decent  looking  print-out. 

uabs  vibro  contrlr  u.out  <  vibro  contrlr  list  |  ulist  »  temp  print 


AH.  FILENAME  C.BAT 

Srem  Make  csource  the  current  subdirectory. 

cd  vibro  contrlr  csource 

Sram  Compile  the  sourca  fila. 

UCCZ80  -a  -1  -A  -L  —  XI 

Sram  Place  the  resultant  object  module  in  tha  objact  subdirectory, 
copy  *.o  ',vibro' contrlr  objact 
erase  «.o 

Sram  Placa  tha  resultant  assembly  listing  in  tha  list  siMiractory. 
copy*.  1st  vibro  contrlr. list 

erase  «.lst 
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AI.  FILENAME  LINK.BAT 


dram  MaKa  objaci  'tha  currant  subdiractory. 
cd  vibro  contrlr  objact 

3raiii  Link  tha  apacifiad  objact  modulas  togathar. 
ula  -f  apae  -t  -v  XI  XZ  XI  X4  X5  X6  X7  X8  X9 

dram  Placa  tha  linKad  modula  in  tha  contrlr  aubdiractory  aa  u.out. 
copy  *.out  vibrocontrlr 
araaa  «.out 

3ram  Craata  an  axacutabla  modula  in  tha  contrlr  aubdiractory  aa  u.bin. 

cd  vibrocontrlr 

ufihex  u.out  >  vibro. hax 


AJ.  FILENAME  LIST.BAT 

Srem  Produce  a  paginated  listing  of  tha  specified  file*  and 
3rem  put  it  in  a  temporary*  scratch  file  called  temp  print, 
ulist  -d  -t  4  -X  -0  hdr=Xl  XI  >>  temp  print 


AK.  FILENAME  LOADMAP.BAT 

Srem  Create  a  load  map  of  all  the  regions  in  u.out. 
unm  -ffl  vibro  contrlr  u.out  >  temp  temp 
3rem  Produce  a  paginated  print-out  of  it. 
ulist  -d  '0  hdr-loadmap  temp  temp  »  temp  print 


AL.  FILENAME  PRINTALL.B.4T 

3rem  Produce  a  complete  listing  of  tha  load  map*  symbol  table  and 

Srem  all  source  files*  and  header  files. 

cd  vibro  contrlr 

call  readyout 

call  loadmap 

call  promsym 

call  o 

call  list  spec 
call  h 

call  list  version. h 
call  cs 

call  list  version. c 
call  h 

call  list  vibro. h 
call  list  bubble. h 
call  ca 

call  list  bubble. c 
call  h 

call  list  bubrw.h 
call  s 

call  list  bubrM.s 
call  h 

call  list  clock. h 
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c«ll 

cs 

call 

list 

clock. c 

call 

h 

call 

list 

convart.h 

call 

cs 

call 

list 

convart.o 

call 

h 

call 

list 

dalay.h 

call 

s 

call 

list 

dalay.s 

call 

h 

call 

list 

axpant.h 

call 

cs 

call 

list 

axpant.c 

call 

h 

call 

list 

global. h 

call 

cs 

call 

list 

global. c 

call 

h 

call 

list 

initial. h 

call 

cs 

call 

list 

initial. c 

call 

h 

call 

list 

inout.h 

call 

cs 

call 

list 

inout.c 

call 

h 

call 

list 

main.h 

call 

cs 

call 

list 

main.c 

call 

s 

call 

list 

mbrk.s 

call 

h 

call 

list 

nawio.h 

call 

s 

call 

list 

nawio.s 

call 

h 

call 

list 

power .h 

call 

cs 

call 

list 

power. c 

call 

list 

s.bat 

call 

list 

start. s 

call 

b 

call 

list 

asm. bat 

call 

list 

asmlist.bat 

call 

list 

b.bat 

call 

list 

bacKupl.bat 

call 

list 

backtp2.bat 

call 

list 

c.bat 

call 

list 

cs.bat 

call 

list 

link.bat 

call 

list 

list.bat 

call 

list 

loa^nap.bat 

call 

list 

o.bat 

call 

list 

printall.bat 

call 

list 

promlib.bat 

call 

list 

promlink.bat 
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call  lict  premsym.bat 
call  list  raadyout.bat 


AM.  FILENAME  PROMLINK.BAT 

cd  vibro  contrlr  object 
link  -F  linkfila  libc.a 

AN.  FILENAME  PROMOUT.BAT 

Sram  Put  tha  print  scratch  fila  into  tha  printer  queue. 

copy  ,vibro  contrlr  batch, lpfont«, tamp .print«yibro  contrlr  batch.normfont  .tanp  printZ 
print  ^teinpprintZ 


AO.  FILENAME  PROMSVM.BAT 

3ren  Put  the  symbol  from  u.out  into  a  scratch  file. 

unm  -fnrstvPgx  vibro  contrlr  u.out  >  tamp  temp 

3rem  Produce  a  paginated  version  of  the  symbol  table  listing. 

ulist  -d  -0  hdr^symbols  temp  temp  »  temp  print 


AP.  FILENA.ME  READYOUT.BAT 

Srem  Get  rid  of  the  two  scratch  files  used  in  producing  listings, 
erase  temp  temp 
erase  temp  print 
erase  temp  printZ 
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APPENDIX  I.  RS-232C  INTERFACE  PIN  CONNECTIONS 


This  appendix  contains  the  complete  electrical  specification  for  the  RS-232C  Inter¬ 
face.  It  is  provided  here  for  convenience.  Only  a  subset  of  this  specification  has  been 
implemented  in  the  Vibro-acoustic  Experiment  for  the  purpose  of  providing  communi¬ 
cations  between  the  controller  and  the  terminal,  which  is  useful  during  ground  testing. 


Table  16.  RS-232C  INTERFACE  PIN  CONNECTIONS 


Pin 

Number 

Circuit 

Desig¬ 

nation 

Mne¬ 

monic 

Desig¬ 

nation 

Direction 

Description 

1 

AA 

FG 

FR-AME  GROUND.  This  lead  is 
an  electircal  equipment  frame  and 
power  ground. 

■) 

BA 

TD 

To  DCE 

TR.ANS.\I1TTED  DATA.  This 
lead  carries  the  serial  digital  data 
transmitted  from  tlie  DTE  to  the 
DCE. 

3 

BB 

RD 

To  DTE 

RECEIVED  DAT.\.  This  lead 
carries  the  serial  digital  data  re- 
ceited  at  the  DTE. 

4 

CA 

RTS 

To  DCE 

REQUEST  TO  SEND.  An  -ON" 
condition  on  this  lead  is  used  to 
enable  the  local  DCE  for  data  tran¬ 
smission. 

5 

CB 

CTS 

To  DTE 

CLEAR  TO  SEND.  An  "ON" 
condition  on  this  lead  indicates 
whether  or  not  the  DCE  is  ready  to 
transmit  data. 

6 

CC 

DSR 

To  DTE 

DATA  SET  READY.  An  “ON" 
condition  on  this  lead  indicates  that 
the  local  DCE  is  ready  to  process 
data  and  is  not  in  a  test,  talk,  or  dial 
mode. 

Source:  Couch,  L.  W.,  Digital  and  Analog  Communication  Systems,  Macmillan  Pub¬ 
lishing  Company,  1987,  pp.  684-686 
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Table  17.  RS-232C  INTERFACE  PIN  CONNECTIONS  (CONTINUED) 


Pin 

Number 

Circuit 

Desig¬ 

nation 

Mne¬ 

monic 

Desig¬ 

nation 

Direction 

Description 

7 

AB 

SG 

SIGNAL  GROUND.  This  lead  es¬ 
tablishes  the  common  ground  refer¬ 
ence  potential  for  all  circuits  except 
frame  ground  on  pin  1. 

8 

CF 

DCD 

To  DTE 

DATA  CARRIER  DETECT  (Re¬ 
ceived  Line  Signal  Detector).  This 
lead  indicates  that  data  from  the 
remote  location  is  being  received 
and  meets  a  suitable  criterion  es¬ 
tablished  by  the  DCE  manufac¬ 
turer. 

9 

To  DTE 

Positive  DC  Test  Voltage 

in 

To  DTE 

Negative  DC  Test  Voltage 

11 

Bell 
:nSA 
type  cir¬ 
cuit 

QM 

To  DTE 

EQUALIZER  .MODE.  This  lead  is 
used  to  indicate  to  the  DTE  that  the 
adaptive  equalizer  in  the  receiver  is 
reset  automatically  when  error  per¬ 
formance  is  poor.  (non-EI.-\  desig¬ 
nated). 

i: 

SCF 

(S)DCE 

To  DTE 

SECONDARY  DATA  CARRIER 
DETECT.  This  lead  is  equivalent 
to  DCD  on  pin  8  except  that  it  in¬ 
dicates  the  proper  reception  of  the 
secondary  channel  line  signal  in¬ 
stead  of  the  primary  channel  re¬ 
ceived  line  signal. 

13 

SCB 

(S)CTS 

To  DTE 

SECONDARY  CLEAR  TO  SEND. 
This  lead  is  equivalent  to  CTS  on 
pin  5  except  that  it  indicates  the 
availability  of  the  secondary  chan¬ 
nel  instead  of  indicating  the  avail¬ 
ability  of  the  primary  channel  to 
transmit  data. 

Source:  Couch,  L.  W.,  Digital  and  Analog  Communication  Systems,  Macmillan  Pub¬ 
lishing  Company,  1987,  pp.  684-686 
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Table  18.  RS-232C  INTERFACE  PIN  CONNECTIONS  (CONTINUED) 


Pin 

Number 

Circuit 

Desig¬ 

nation 

Mne¬ 

monic 

Desig¬ 

nation 

Direction 

Description 

14 

SBA 

(S)TD 

To  DCE 

SECONDARY  TRANSMITTED 
DATA.  This  lead  is  equivalent  to 

TD  on  pin  2  except  that  it  is  used 
to  transmit  data  via  the  secondary 
channel. 

Bell 
208A 
type  cir¬ 
cuit 

NS 

To  DCE 

NEW  SYNC.  This  lead  may  be 
used  on  an  optional  basis  with  the 
DCE  at  a  master  station  of  a  mul¬ 
tistation  private  line  network,  such 
as  in  a  polling  operation,  to  ensure 
rapid  resynchronization  of  the  re¬ 
ceiver  on  data  from  many  different 
remote  transmitters  (non-El.A  des¬ 
ignated). 

15 

DB 

TC 

To  DTE 

TlUANSMTl TER  CLOCK.  This 
lead  is  used  to  provide  the  DTE 
with  signal  element  timing  informa¬ 
tion. 

16 

i 

SBB 

(SjRD 

1 

To  DTE 

j 

SECONDARY  RECEIVED 

D.AT.A.  This  lead  is  equivalent  to 

RD  on  pin  3  except  that  it  is  used 
to  receive  data  on  the  secondary 
channel. 

Bell 
20SA 
type  cir¬ 
cuit 

DCT 

To  DTE 

DIVIDED  CLOCK.  TFC\NSM1T- 
TER.  .-\  square-wave  signal  at 
one-third  the  nominal  bit  rate  ap¬ 
pears  on  this  lead  whenever  power 
is  supplied  to  the  DCE  {non-ElA 
designated.). 

Source;  Couch,  L.  W.,  Digital  and  Analog  Communication  Systems,  Macmillan  Pub¬ 
lishing  Company,  1987,  pp.  684-686 
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Table  19.  RS-232C  INTERFACE  PIN  CONNECTIONS  (CONTINUED) 


Pin 

Number 

Circuit 

Desig¬ 

nation 

Mne¬ 

monic 

Desig¬ 

nation 

Direction 

Description 

17 

DD 

RC 

To  DTE 

RECEIVER  CLOCK.  This  lead  is 
used  to  provide  the  DTE  with  re¬ 
ceived  signal  element  timing  infor¬ 
mation. 

18 

Bell 
208A 
type  cir¬ 
cuit 

DCR 

To  DTE 

DIVIDED  CLOCK,  RECEIVER. 

A  square-wave  signal  on  this  lead 
provides  the  receiver  timing  infor¬ 
mation  at  one-third  the  nominal  bit 
rate  (non-ELA  designated). 

19 

SCA 

(S)RTS 

To  DCE 

SECONDARY  REQUEST  TO 
SEND.  This  lead  is  equivalent  to 
RTS  on  pin  4  except  that  it  requests 
to  use  the  secondarx’  channel  in¬ 
stead  of  the  primary  data  channel. 

2<.) 

CD 

DTR 

To  DCE 

DATA  TERMINAL  READY.  An 
"ON*’  condition  on  this  lead  indi¬ 
cates  that  the  DTE  is  ready  to  be 
connected  to  the  conununication 
channel. 

21 

CG 

SQ 

To  DTE 

SIGNAL  QUALITY  DETECT. 

This  lead  is  used  to  indicate  whether 
or  not  there  is  a  high  probability  of 
an  error  in  the  received  data. 

Source;  Couch.  L.  W..  Digital  and  Analog  Communication  Systetns,  Macmillan  Pub¬ 
lishing  Company,  19S~,  pp.  6S4-6S6 


r 
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Table  20.  RS-232C  INTERFACE  PIN  CONNECTIONS  (CONTINUED) 


Pin 

Number 

Circuit 

Desig¬ 

nation 

Mne¬ 

monic 

Desig¬ 

nation 

Direction 

Description 

22 

CE 

RI 

To  DTE 

RING  INDICATOR.  An  “ON” 
condition  on  this  lead  indicates  that 
a  ringing  signal  is  being  received  on 
the  communication  channel. 

23 

CH 

To  DCE 

DATA  RATE  SELECTOR.  This 
lead  is  used  to  select  between  the 
two  data  signalling  rates  in  the  case 
of  dual  rate  DCE. 

Cl 

To  DTE 

D.ATA  1C-\TE  SELECTOR.  This 
lead  is  used  to  select  between  the 
two  data  signalling  rates  in  the  case 
of  dual  rate  DCE. 

24 

DA 

TC 

1  0  DCE 

EXTERNAL  TR,-\NSM1TTER 
CLOCK.  This  lead  is  used  to  pro¬ 
vide  the  transmitting  signal  con¬ 
verter  with  signal  element  tinung 
information. 

25. 

Bell 
208A 
type  cir¬ 
cuit 

1 

To  DCE 

BUSY.  This  lead  is  used  for  testing 
purposes  by  Telephone  Company 
personnel  (non-ELA  designated). 

Source:  Couch.  L.  W.,  Digital  and  Analog  Communicaiion  Systems,  Macmillan  Pub¬ 
lishing  Company,  1987,  pp.  684-686 
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